[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force      H.Zandbelt, B.Hulsebosch, H.Eertink
Internet Draft                                      Telematica Instituut
draft-zandbelt-idsec-01.txt                                     May 2002


                IDsec: Virtual Identity on the Internet


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   IDsec is a mechanism that provides an identity for users on the
   Internet. Identity in IDsec means that a user is known by a certain
   profile that contains precisely those attributes that the user wants
   to reveal to the requester of his profile. Access to profile
   attributes is managed by the user himself. Certificates and
   public/private key mechanisms ensure that information is exchanged in
   a secure way only between parties that trust each other.

Table of Contents

   1.  Introduction....................................................2
   2.  Overview........................................................2
   3.  Definitions.....................................................3
   4.  Profiles........................................................4
   5.  Access Control Lists............................................5
   6.  Trusted Certificates............................................6
   7.  Session Certificate.............................................6
   8.  Profile Manager.................................................7



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 1]


Internet Draft                    IDsec                         May 2002


   9.  Profile Owner..................................................10
   10. Profile Requester..............................................11
   11. Relationship between Profile Owner and Profile Manager.........12
   12. Relationship between Profile Requester and Profile Manager.....13
   13. Relationship between Profile Owner and Profile Requester.......14
   14. Content Distribution Network Provider..........................14
   15. Certificate Management.........................................15
   16. Profile Updates................................................15
   17. Usage Scenario's...............................................16
   18. Conclusion.....................................................16
   19. Security Considerations........................................16
   20. References.....................................................16
   21. Author's Addresses.............................................17
   22. Acknowledgments................................................18
   Appendix A: Interaction Diagrams...................................18
   Appendix B: Profile DTD............................................19
   Appendix C: Example Profile Attributes.............................19

1.  Introduction

   Today many services exist on the Internet that require some form of
   user identification or user information, e.g. for personalisation or
   e-commerce purposes. These services rely on customer information to
   improve their quality by using previously acquired knowledge about
   users stored in user profiles. However each of these services
   implements its own mechanism for that purpose, wich leads to user
   information redundancy, fragmentation and possible inconsistency.
   Moreover the current situation forces users to maintain multiple
   profiles at multiple service providers. This overload of personal,
   possibly privacy-sensitive, information floating around the Internet
   leads to great issues of trust.

   In this memo we present a generic mechanism for establishing Virtual
   Identities on the Internet, that standardises protocols and
   interfaces for exchanging identity information between users and
   service providers in a secure manner. It enables users to reuse
   profile information across Internet services and service providers to
   delegate (part of) their customer information maintenance.

2.  Overview

   Profiles are stored with so-called Profile Managers somewhere on the
   Internet. Profile Managers are parties that have a trusted
   relationship with the Profile Owners whose Profiles they have stored
   in their databases.

   A Profile Manager runs a server application that allows his clients
   to modify their Profile over a secure connection. In addition to



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 2]


Internet Draft                    IDsec                         May 2002


   modification of attributes and their values, Profile Owners can
   assemble Access Control Lists that specify which attributes are
   accessible to which Profile Requesters. Access Control Lists are
   based on certificate [9] information.

   Upon starting an Internet action that requires the use of IDsec, a
   Profile Owner will login with the Profile Manager. This "session
   login" will result in the creation of a "session certificate" that is
   sent to the Owner. The session certificate represents the Owner in
   the current Internet session and it contains a reference to the
   location of his Profile.

   The Profile Owner sends the session certificate to the IDsec enabled
   Profile Requester. The Requester in his turn, sends it together with
   his own root certificate to the location specified in the session
   certificate. The Profile Manager uses the session certificate to
   identify the Owner and to assemble a Profile Requester specific
   Profile based on the Requester credentials and the Access Control
   List that the Owner specified.

   The Profile Requester now has a customer Profile that he can use to
   personalize content, to do accounting and/or billing (eventually in
   combination with a third party) and any other business that he would
   normally do with locally stored customer data.

   Notice that IDsec supports "anonymous browsing" and single sign-on;
   it does not neccesarily reveal the name and address of the Profile
   Owner or any other attribute that uniquely identifies the Profile
   Owner. IDsec transmits exactly those attributes that an Owner trusts
   to be sent to the Requester.

3.  Definitions

   Attribute

      A name-value pair in a Profile.

   Profile

      A set of attributes that represents a Profile Owner on the
      Internet.

   Profile Owner (or Owner)

      A role for a party on the Internet that wants Profile Requesters
      to associate him with a certain Profile.

   Profile Requester (or Requester)



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 3]


Internet Draft                    IDsec                         May 2002


      A role for a party on the Internet that wants to associate another
      party with a Profile.

   Profile Manager (or Manager)

      A role for a party on the Internet that stores a Profile for a
      Profile Owner and makes it accessible for Profile Requesters.

4.  Profiles

   A Profile is a data record that contains information about a certain
   Profile Owner. It represents an Owner and as such it can be helpful
   in many circumstances on the Internet. In the IDsec system, the
   information that is typically found in legacy user profiles like
   name-address type of information, may be extended with information
   that has a more dynamic, session-oriented nature. Examples are
   presence related information and terminal related settings.

   A basic Profile contains vCard-like [11] information such as:

      Name
      Address
      Telephone Number
      E-mail address
      Date of birth

   In addition to that it may contain billing-related information such
   as:

      Creditcard data
      Bank-account data

   This is expected to be valuable in the e-commerce type of web-
   services. Furthermore a Profile could contain user preferences such
   as:

      Home environment specific data
      Application specific data
      Service Provider specific data

   The IDsec Profile consists of a set of name-value tuples called
   attributes.  The attribute namespace is a directory like hierarchy
   thus supporting namespaces. A typical attribute example is:

      "private.address.zipcode"

   or




H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 4]


Internet Draft                    IDsec                         May 2002


      "billing.creditcard.expirydate".

   A Profile can be stored in a Manager specific way but it is presented
   and transferred to Requesters in a simple XML format with the DTD
   found in Appendix B - Profile DTD. A typical Profile example is:

      <profile>
         <context name="private"><context name="address">
            <attribute name="zipcode">
               <value>
                  7500 AN
               </value>
            </attribute>
         </context></context>
         <context name="billing"><context name="creditcard">
            <attribute name="expirydate">
               <value>
                  01/01/2004
               </value>
            </attribute>
         </context></context>
      </profile>

   All attributes that can be found in a Profile must be standardized
   and must therefore be described in standards documentation. However
   the defined set is expected to be extended on a regular basis. The
   standard must also specify the type of the value and how it should be
   interpreted. This document does not attempt to standardize
   attributes; only example attributes names and their value types have
   been defined so far. (see Appendix C - Example Profile Attributes).

5.  Access Control Lists

   In addition to an attribute value, the Profile Manager also offers
   the possibility of defining and storing an Access Control List (ACL)
   for each attribute. An ACL specifies exactly which Requesters have
   read-access to the attribute value. ACL values are based on
   information found in a certificate [9] (called Requester certificate)
   that a Requester has to present to get access to a specific
   attribute. An Access Control List consists of one or more Access
   Control Elements (ACE). Each ACE consists of 4 elements:

   o  Distinguished Name

      This field contains a regular expression that needs to be matched
      against the Distinguished Name field that is presented in the
      Requester certificate. In case the Distinguished Name field is
      empty, the additional name forms that are conveyed in the subject



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 5]


Internet Draft                    IDsec                         May 2002


      alternative names extension are used [9]. Especially domain names
      will be used in this context.

   o  Organization

      This field contains a regular expression that needs to be matched
      against the Organization field that is presented in the Requester
      certificate.

   o  Organizational Unit

      This field contains a regular expression that needs to be matched
      against the Organizational Unit field that is presented in the
      Requester certificate.

   o  Issuer

      This field contains a reference to the root certificate of the
      Certificate Authority that issued the Requester certificate. This
      issuer's root certificate is also stored with the Profile Manager
      so it can be used to validate the signature on the Requester
      certificate. (see Trusted Certificates)

   In order to be able to read the attribute value that the ACL is
   associated with, the Requester must present a certificate that
   matches one or more of the ACEs in the ACL on all four fields. In
   other words: ACEs are inclusive: Requester access to the attribute is
   disabled by default. ACEs are compared one-by-one; when a positive
   match is found, the search is stopped and access is granted.

   A special value ACL exists that denotes a so-called "public"
   attribute, ie. an attribute that is readable by any Requester.

   A future specification of ACLs might also incorporate certification
   policy. A Profile Owner could be willing to release certain
   attributes to any party that holds a certificate issued under a
   particular policy.

6.  Trusted Certificates

   The Profile Manager must offer the possibility of uploading and
   storing root certificates of Certificate Authorities that are trusted
   by the Profile Owner. Each Owner can upload his own trusted
   certificates that have to be used to validate the Requester
   certificates. In addition to the "personal" trusted certificates, a
   Profile Manager may predefine a set of root certificates that he
   considers to be trusted. This would prevent him from storing for
   example, Verisign root certificates, several times for multiple



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 6]


Internet Draft                    IDsec                         May 2002


   Profile Owners. Notice that this does not neccesarily mean that an
   Owner automatically trusts these certificates; he can choose not to
   use these predefined certificates in his ACLs.

7.  Session Certificate

   This certificate identifies the Profile Owner's Internet session in
   the context of a Profile Manager. The certificate itself does not
   reveal any information about the Owner; it serves as a pointer to a
   Profile. The information in the Session Certificate consists of the
   following components:

   o  Session Identifier

      The session identifier serves as a pointer to the session,
      meaningful only in the environment of the Profile Manager where
      the certificate was created. Although it uniquely identifies a
      session, and therefore points to a specific Owner, the identifier
      itself must be constructed in such a way that it does not reveal
      information about the session or the Owner of the session.

   o  Profile Manager Location

      This is a reference to the Profile Retrieve Service (see Profile
      Retrieve Service). This service can be used to retrieve the
      Profile of the Owner associated with the session certificate
      (after authentication and authorization of the Requester).

   o  Profile Manager Signature

      The Session Certificate is signed by the Profile Manager so the
      integrity of the data in the certificate can be verified by the
      Profile Manager when it is presented by a Requester for Profile
      retrieval. In case of a trusted relationship between Profile
      Requester and Profile Manager (see Relationship between Profile
      Requester and Profile Manager), the Requester can also check the
      integrity of the certificate.

   o  Public Key

      The public key in the Session Certificate is generated by the
      Profile Owner together with a private key that is stored on his
      local system. Whenever information needs to be passed in a secure
      manner from Profile Requester to Profile Owner, the public key can
      be used by the Requester to encrypt the data. The Owner can use
      the corresponding private key to decrypt the data.

   o  Expiration Date



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 7]


Internet Draft                    IDsec                         May 2002


      The Session Certificate contains an expiration date so that the
      certificate cannot be reused after the specified date. This
      enables a Manager to manage the amount of (unused) session data in
      an efficient way.

8.  Profile Manager

   The Profile information is stored by a so-called Profile Manager that
   is trusted by the Profile Owner. Notice that it is possible for a
   Profile Owner to act as his own Profile Manager (see Profile
   Management Service). A Profile Manager enables a Profile Owner to
   manage his Profile and he offers access to Profile information to
   interested third parties such as Internet Service Providers and
   Content Distribution Network Providers. Three services must be
   offered by the Profile Manager:

   o  Profile Management Service

      This is a service that a Profile Owner can access to manipulate
      his Profile data. In the case of a Profile Manager operating for
      multiple Owners, it is likely that all data is stored in a back-
      end database server. The Profile Management Service is accessed by
      means of a client application that an Owner can use to manipulate
      Profile attributes, their values, their ACLs and the stored
      certificates.

      Strictly spoken the client application and the communication
      between Profile Manager and Profile Owner can be Manager specific
      and needs not to be standardized by this document. One could even
      operate a so-called Local Profile Manager, implemented as a
      service running on the Owner machine, where communication is done
      through function calls to libraries.

      However, all external communication must be done over a secure
      encrypted channel. Upon establishing this channel, both parties
      must be able to verify each other by means of commonly agreed
      authentication mechanisms. The Owner credentials are possibly, but
      not necessarily, stored as ordinary (non-externally accessible)
      Profile attributes. A typical solution would be a HTTPS [4]
      connectivity where a Profile Manager server certificate must be
      presented to the Owner when the connection is initiated (see
      Profile Owner - Profile Management Application).

   o  Session Login Service

      A Profile Manager runs a Session Login service that provides
      Session Certificates to Profile Owners. When an Owner successfully
      logs into this service with Manager specific credentials, a so-



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 8]


Internet Draft                    IDsec                         May 2002


      called session is established. In addition to credentials, the
      Owner must also present the public key of a dynamically created
      public/private keypair. As a result of the login phase a Session
      Certificate is returned to the Owner (see Session Certificate).

      Similar to the Profile Management Service, the Session Login
      service can be implemented in a Manager specific way. However a
      typical solution would again be a service over an HTTPS connection
      in which the Profile Manager authenticates himself with a server
      certificate (see Profile Owner - Session Login Application).

   o  Profile Retrieve Service

      This is a service that a Profile Requester can access to retrieve
      a Profile Owner's Profile. The Requester presents a Session
      Certificate sent by the Owner together with his own Requester
      certificate to the Profile Retrieve Service in the Profile
      request. The Profile Retrieve Service verifies the Session
      Certificate and uses the session identifier to find the Owner that
      is associated with the session. The Profile Manager verifies the
      Profile Requester certificate by means of the trusted certificates
      that the Owner stored with his Profile (see Trusted Certificates).
      Upon successful verification, a Requester specific Profile is
      assembled by interpreting the Access Control Lists for each
      attribute.  An XML formatted subset of attributes (see Profiles)
      is sent in the Profile response to the Requester.

      The communication channel must be made secure by using
      public/private key encryption techniques. Several communications
      channels may be defined that ultimately return an encrypted
      Profile. The type of channel will be reflected in the Profile
      Manager location reference that is transferred in the Session
      Certificate. Two communication channels have been defined so far:

      1) HTTP

         A URL [7] of the form "http://<host>/<path>" indicates that the
         request for a Profile is sent over plain HTTP [3] and that the
         Profile is returned as a encrypted data in a plain HTTP
         response. The HTTP request data consists of the Profile
         Requester certificate, which is checked against the Access
         Control Lists of the Profile attributes.

         Notice that this scheme implies that any data that is sent
         along with the request (possible indications about subsets of
         Profiles, or Requester specific extensions) is unencrypted. A
         default request will contain only public data in which case
         this is not a security problem. The HTTP response data,



H.Zandbelt, B.Hulsebosch, H.Eertink                             [Page 9]


Internet Draft                    IDsec                         May 2002


         consisting of the XML formatted Profile (see Profiles) must be
         encrypted with the public key that is found in the Profile
         Requester certificate.

      2) HTTPS

         A URL [7] of the form "https://<host>/<path>" indicates that
         the request and the response for a Profile is sent over a HTTPS
         [4] connection. The HTTPS connection is setup with the Profile
         Requester certificate as a client certificate and the Profile
         Manager certificate as the server certificate.

         Notice that the exchanged certificates cannot be checked by the
         Profile Manager nor by the Profile Requester because in general
         they don't have a trusted relationship (see Relationship
         between Profile Requester and Profile Manager). However we
         choose for defining an HTTPS communication mechanism since it
         is a convenient means of secure communication, which meets our
         demand for encryption. Future extensions of the request format,
         (for example primitives to ask for a subset of a Profile, or
         Requester specific data) will perhaps require encryption of the
         request, which in that case is already covered by HTTPS.

      3) Local

         A URL of the form "local://" indicates that the user operates
         as a so-called Local Profile Manager. In this case the request
         for a profile can be sent to the Profile Owner over the same
         communication channel that was used to send the Session
         Certificate, possibly as a response message. The request data
         must contain only the Profile Requester certificate as the
         Session Certificate is known to the Profile Owner already. The
         Profile data returned by the Owner, will be encrypted with the
         public key found in the Profile Requester certificate.

         This protocol is adopted to enable a Profile Owner to operate
         as a light-weight Profile Manager. Profile Management software
         may be linked against the client application in this case, so
         running a separate, possibly heavy-weight, Profile Management
         Service as a standalone server application is no longer
         necessary (see also Profile Manager - Profile Management
         Service).

9.  Profile Owner

   At the client side three seperate functionalities can be
   distinguished:




H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 10]


Internet Draft                    IDsec                         May 2002


   o  Profile Management Application

      Profile maintenance is done by logging into the Profile Management
      Service (see Profile Manager - Profile Management Service). A
      client application is used to edit Profile attributes, their
      values, their ACLs and the stored certificates. Both sides must
      authenticate each other and a secure communication channel must be
      established.

      All components (application, service, authentication and channel)
      may be Manager specific.

      Typically a Profile Owner will gain access to the Profile
      Management Service with a username/password combination and the
      Profile can be manipulated through a set of HTML [6] pages in a
      browser over an HTTPS connection. A Profile Manager server
      certificate will be presented to the Owner who must be able to
      verify it.

   o  Session Login Application

      Upon entering an IDsec enabled Internet site, the Profile Owner
      will be asked for a Session Certificate (see Session Certificate).
      To receive a Session Certificate, an Owner must log into the
      Session Login Service (see Session Login Service) with his Manager
      specific credentials, likely to be the same as he uses for the
      Profile Management Service (see Profile Management). In addition
      to that, he needs to generate a public/private keypair and include
      the public key in the Session Login request. As a result of that
      action, a Session Certificate will be returned, containing the
      public key sent in the request and signed by the Profile Manager
      (see Session Certificate).

      Similar to the Profile Management Service, the Session Login
      service can be implemented in a Manager specific manner.

      Typically an Owner will log into the Session Login Service with a
      username/password combination over an HTTPS connection where a
      server certificate will identify the Profile Manager.

   o  Session Certificate Handler

      At the client side, functionality is needed to extend Internet
      service requests with Profile related information and to be able
      to interpret any Profile related responses from IDsec enabled
      Internet sites. A typical way to offer this functionality is by
      means of a service specific plugin or a generic Internet proxy.
      The handler will intercept Session Certificate requests from IDsec



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 11]


Internet Draft                    IDsec                         May 2002


      enabled sites and it will present the certificate that is
      retrieved by the Session Login Application. After doing so, a
      specific Internet request header will be included with every
      following request that serves as a pointer to the Session
      Certificate, so that the certificate itself does not need to be
      passed with every request.

      When the Profile Requester wishes to verify the Owner of the
      Session Certificate, he must send challenge data (see Profile
      Requester - Encryption Handler) that will be answered by the
      handler, using the private key generated in the Session Login
      phase. For details the reader is referred to Appendix A -
      Interaction Diagrams.

10. Profile Requester

   Any party on the Internet, for example an Internet Service Provider,
   that is interested in the Profile of a user that is accessing his
   Internet site, can use IDsec software to get access to the Profile
   attributes; by doing so, he is called a Profile Requester in the
   IDsec terminology. To that purpose the Profile Requester may use
   IDsec software suited for use in the specific server environment that
   he operates. The IDsec library must offer the following
   functionality:

   o  Session Certificate Request Component

      The Profile Requester uses this component to intercept any non-
      IDsec-aware requests that the Owner sends and to ask for a Session
      Certificate. If a Session Certificate cannot be presented by the
      Owner (possibly because he is a non-IDsec-aware user), normal
      operation is resumed, otherwise the Profile Request Component will
      be used to get access to the Profile data of the Owner associated
      with the Session Certificate.

   o  Profile Request Component

      This software component is a client application of the Profile
      Retrieve Service. It extracts the Profile Manager location
      reference from the Session Certificate and sends a request for a
      Profile to that location. The Profile request must contain both
      the Session Certificate and the Profile Requester certificate (see
      Profile Retrieve Service).

   o  Encryption Handler

      A Profile Requester cannot be sure of the identity of the Owner
      based only on the sending of the  Session Certificate. That



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 12]


Internet Draft                    IDsec                         May 2002


      certificate may have been snooped and (re)used by a malicious
      user. Therefore he may want to verify that the sender of the
      Session Certificate is the rightful owner by using the Encryption
      Handler. It will send challenge data encrypted with the public key
      in the Session Certificate. Upon a successful response (see
      Profile Owner - Session Certificate Handler), the Requester can be
      sure that the session certificate was sent by the party that owns
      the corresponding private key, thus the owner of the certificate.

      In general a Profile Requester must encrypt any privacy sensitive
      data that is sent to the Owner with the Session Certificate public
      key. For large amounts of data or streaming data, a secure data
      channel may be established using the Session Certificate public
      key. A TLS [5] connection is a convenient example.

   Notice that the trusted relationship between Owner and Requester (see
   Relationship between Profile Owner and Profile Requester) also
   implies that the Requester must not send unencrypted content that
   reveals any access-restricted Profile information about the Owner.
   For example: a Web Service Provider cannot do content adaptation of
   HTML pages for Owner Bob saying "Hello Bob", if the attribute
   containing the name "Bob" is not a public attribute.

11. Relationship between Profile Owner and Profile Manager

   A trusted relationship must exist between an Profile Owner and his
   Profile Manager.

   o  A Profile Owner must trust the Profile Manager

      The Owner stores his privacy-sensitive data at the Manager. He
      trusts the Manager to protect his privacy sensitive data and to
      enforce the Access Control policies on the Requesters.

   o  A Profile Manager must trust a Profile Owner

      The Manager has a customer-provider relationship with the Owner.
      Before accepting an Owner as a customer, the Profile Manager will
      ensure that the Owner is a trustworthy partner with respect to
      billing and abuse of the system. A Service Level Agreement may
      exist between Owner and Manager so that when either the Manager
      does not meet the quality of service, or the Owner breaks the
      rules, the contract will be ended.

12. Relationship between Profile Requester and Profile Manager

   A trusted relationship between a Profile Requester and a Profile
   Manager may exist.



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 13]


Internet Draft                    IDsec                         May 2002


   o  A Profile Manager may not trust a Profile Requester

      The Profile Requester certificate for the Profile request is used
      in the communication with the Manager without being trusted by the
      Manager itself. The certificate, or to be more precisely, the
      public key is only used to encrypt the Profile data that has to be
      returned in a secure manner. This ensures that only the rightful
      owner of the Requester certificate and thus the Owner of the
      corresponding private key, is able to read the Profile.

      The Owner himself determines to which level the Profile Requester
      is trusted and thus which Profile information he is allowed to
      access. He does so by specifying Access Control Lists and storing
      trusted certificates. The Profile Retrieve Service verifies
      certificates on behalf of the Owner because the Owner trusts him
      to do so (see Relationship between Profile Owner and Profile
      Manager).

   o  A Profile Requester may not trust a Profile Manager

      1) Non-Trusted

         The non-trusted case works similar to current e-commerce web-
         sites; information that is entered (ie. provided by the Profile
         Manager), needs to be verified (if needed at all) in some
         other, possibly non-electronic way. Requester specific
         credentials or a creditcard number are typical Profile
         attributes that need verification in this scenario. (see
         Relationship between Profile Owner and Profile Requester)

      2) Trusted

         In the trusted case, a Profile Requester asks for a Profile
         Manager certificate at the beginning of establishing a
         communication channel. The certificate is verified by the
         Requester (see Profile Manager - Profile Retrieve Service -
         HTTPS). In this scenario, information provided for a specific
         Owner needs not to be verified. The Manager guarantees the
         correctness of information and the identity of the Owner. The
         party that signed the Profile Manager certificate could be an
         organization that issues certficates to trusted Profile
         Managers, a so-called Profile Manager Root Certificate
         Authority.

      The trusted model may seem to be attractive at first glance, but
      we have to keep in mind that a large number of Profile Managers
      may exist (up to private ones). Moreover this scenario is only
      interesting when there is no prior established relationship



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 14]


Internet Draft                    IDsec                         May 2002


      between Owner and Requester, but there is one already between
      Manager and Requester.

      The bottom line in both cases is that the information returned by
      the Profile Manager can be used to authenticate the Owner that is
      associated with the Session Certificate.

13. Relationship between Profile Owner and Profile Requester

   A trusted relationship between an Profile Owner and a Profile
   Requester may exist.

   o  A Profile Owner may trust a Profile Requester

      An Owner specifies Access Control Lists that specify to exactly
      which attributes a Requester may access (see Access Control Lists)
      in addition to the so-called "public" attributes. In the case of
      non-public attributes, the Owner trusts the Profile Requester with
      the information: he assumes that his private information is
      securely kept within the Requester domain.

   o  A Profile Requester may trust a Profile Owner

      The Requester trusts an Owner based on, possibly Requester
      specific, information found in the Profile and only after
      verifying the Owner of the Session Certificate (see Profile
      Requester - Encryption Handler).

      An alternative to requester specific credentials can be the use of
      a trusted-third-party. This would be a well-known party trusted by
      both the Profile Requester and the Profile Owner. If the Profile
      Owner is able to present credentials that can only have been
      issued by the trusted-third-party, the Profile Requester may
      decide to trust the provided Profile data without additional
      checks. The validity of the data would be ensured by the trusted-
      third-party in that case.

14. Content Distribution Network Provider

   An Internet Service Provider may wish to delegate the tasks of
   content hosting and content adaptation to a Content Distribution
   Network Provider (CDN Provider). A CDN Provider can perform these
   tasks for several Service Providers in an optimized way. In order to
   be able to adapt content on behalf of a Service Provider, the CDN
   Provider needs to get access to the Profile data that the origin
   Service Provider is allowed to access. He needs Service Provider
   specific credentials to do so.




H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 15]


Internet Draft                    IDsec                         May 2002


   We foresee a solution in which a CDN Provider can use a certificate
   that is signed by the Service Provider to access the Profile data.
   The Profile Manager checks the signature on the certificate against
   Access Control Lists that the Owner has specified for his Profile
   attributes. In that way a CDN Provider is able to act as a Profile
   Requester on behalf of a Service Provider.

15. Certificate Management

   In the IDsec environment, all certificate management is done by
   "traditional" certificate authorities (see also [10]).  Profile
   Requesters need to get a certificate signed by a certificate
   authority. The only exception to this are certificates that a CDN
   Provider may use on behalf of a Service Provider (see Content
   Distribution Network Provider). These certificates have to be signed
   by Service Providers.

   Notice that there is no need for Session Certificate management, as
   all session certificates have a limited usage period. They will
   expire automatically so no certificate revoke lists are needed. The
   Profile Manager can deal with comprimised sessions or malicious users
   by using session- and user-management only.

16. Profile Updates

   As stated before, Profile data may have a dynamic nature (see
   Profiles). Examples of such data are presence related information and
   terminal related settings (audio on/off). This brings up the issue of
   Profile update propagation: how to notify interested parties when a
   Profile changes? We define a subscription mechanism to deal with
   Profile updates. A Profile Requester may subscribe to Profile
   attribute updates by indicating this in the Profile request that he
   sends to the Profile Manager. The request must contain a URI [8] that
   points to a handler that is able to process Profile updates that a
   Manager sends. The Manager manages the subscriber list. We define two
   levels of granularity:

   o  Full

      A full subscriber receives a complete Profile with the latest
      attribute values upon every update of a Profile. This level is
      convenient for less frequent updates; it can easily be implemented
      by reusing the code that handles a normal Profile response.

   o  Partial

      A partial subscriber indicates in which Profile attributes he is
      interested. He will receive an update when such an attribute



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 16]


Internet Draft                    IDsec                         May 2002


      changes and the update contains the single new attribute value
      only. This level is convenient for frequently updated attributes.

   The layout of the update interfaces can be found in Appendix A.

17. Usage Scenario's

   One can think of many scenario's on the Internet where the use of
   secure Profiles as offered by IDsec can bring added value. We would
   like to describe two of them here which we consider to be among the
   more important ones:

   o  Content personalisation while browsing anonymously

      Because IDsec supports a fine granularity of access control to
      Profile attributes, it is possible to restrict access to
      name/address information while offering access to information that
      does not uniquely identify a person. This enables Profile
      Requesters such as Web Service Providers to do content
      personalisation based on, for example, hobbies or favourite color
      whithout forcing the user to reveal his actual identity.

   o  Third party billing

      Accounting, payment and billing can be done in a secure manner by
      relaying it to a trusted third party indicated in the Profile.
      Creditcard data won't be passed to Service Providers but merely to
      a billing party trusted by the Service Provider that also has
      access to the creditcard data in the Profile.

18. Conclusion

   IDsec forms a simple application level solution for establishing
   Virtual Identities on the Internet; it is flexible and extensible. We
   constructed a solution with standard off-the-self components and
   protocols such as HTTP, HTTPS and certificates. IDsec offers support
   for anonymous browsing, single-signon and Profile extensibility. The
   specification does not fix transport protocols or security
   interfaces; it is setup in a modular fashion so improvements can be
   plugged in.

19. Security Considerations

   A main concern for digital identity systems that use a remote
   location for storing data is that users must find a trusted party
   that is able and willing to operate this service for them. As this
   party will have access to all of a persons private data this is a
   crucial issue and choices must be made with care. As it is a risk to



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 17]


Internet Draft                    IDsec                         May 2002


   put all of a persons data with just one Profile Manager, we foresee
   that people will manage multiple identities and thus spread their
   private data across multiple Profile Managers (ie. work, home,
   sports, hobbies).

   A Profile Manager must be able to protect the privacy of the customer
   at all times. As one Profile Manager is likely to store data for
   multiple customers, it is an attractive target for hackers and
   malicous organizations.  System level security is crucial here.

   Furthermore users must realize that they influence the security of
   their data themselves when providing access to Profile Requesters.
   How can one be sure to trust a Profile Requester? That is the key
   question and this memo cannot present a solution for that. If a by
   any mistake, a malicous Profile Requester is granted access, a
   sensitive data leak will have been created; the mistake can be
   corrected but the damage will have been done.  No identity system can
   take responsibility for a users actions nor can it guarantee
   correctness of those actions.

20. References

   [1]   Bradner, S, "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [2]   Bradner, S, "The Internet Standards Process - Revision 3", RFC
         2026, March 1997.

   [3]   Gettys, R, Mogul, J, Frystyk, J, Masinter, H, Leach, L,
         Berners-Lee, P and T Berners-Lee, "Hypertext Transfer Protocol
         - HTTP/1.1", RFC 2616, June 1999.

   [4]   E. Rescorla, "The Secure HyperText Transfer Protocol",
         RFC 2660, August 1999.

   [5]   Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
         January 1999.

   [6]   Raggett, D., "HTML 3.2 Reference Specification", W3C
         Recommendation, January 1997.
         Available at <http://www.w3.org/TR/REC-html32>.

   [7]   Berners-Lee, T., Masinter L., and M. McCahill,
         "Uniform Resource Locators (URL)", RFC 1738, December 1994.

   [8]   Berners-Lee, T, Fielding, R, Irvine, U C and L Masinter,
         "Uniform Resource Identifiers (URI): Generic Syntax", RFC
         2396, August 1998.



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 18]


Internet Draft                    IDsec                         May 2002


   [9]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
         Public Key Infrastructure, Certificate and CRL Profile", RFC
         2459, January 1999.

   [10]  Adams, C. and S. Farrell, "Internet X.509 Public Key
         Infrastructure, Certificate Management Protocols", RFC
         2510, March 1999.

   [11]  Internet Mail Consortium, "vCard - The Electronic
         Business Card Version 2.1",
         http://www.imc.org/pdi/vcard-21.txt, September 18, 1996.

21. Author's Addresses

   Hans Zandbelt
   Telematica Instituut
   Drienerlolaan 5
   7500 AN Enschede
   Netherlands

   Phone: +31 53 4850 445
   EMail: hans.zandbelt@telin.nl

   Bob Hulsebosch
   Telematica Instituut
   Drienerlolaan 5
   7500 AN Enschede
   Netherlands

   Phone: +31 53 4850 498
   EMail: bob.hulsebosch@telin.nl

   Henk Eertink
   Telematica Instituut
   Drienerlolaan 5
   7500 AN Enschede
   Netherlands

   Phone: +31 53 4850 409
   EMail: henk.eertink@telin.nl

22. Acknowledgments

   Thanks to Martin Wibbels and Stanislav Pokraev of Telematica
   Instituut for their contributions. Also thanks to the people on the
   DotGNU Auth mailing list for their suggestions, especially David
   Sugar. Other valuable feedback has been provided by Russ Housley.




H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 19]


Internet Draft                    IDsec                         May 2002


Appendix A: HTTP Interaction Diagrams

Legenda:   ---->  = HTTP request
           <----  = HTTP response
           PR     = Profile Requester
           SC     = Session Certificate
           <PRID> = Profile Requester specific identifier
           <SID>  = Profile Requester specific session identifier

A.1  Profile Owner - Profile Requester Interaction

  Profile Owner       HTTP                     Profile Requester

request to PR  ---------------------> receive non-IDsec enabled request

request for SC <--------------------- request for Session Certificate
               Redirect Temporarily (StatusCode 302)
               Set-Cookie: IDSEC=<PRID>#<SID>#CertificateRequest

send SC        ---------------------> retrieve the Profile
               Cookie: IDSEC=<PRID>#<SID>#CertificateResponse
               request data: <Session Certificate>

adapted data   <--------------------- interpret Profile and adapt

A.2  Profile Owner (non-IDsec-enabled) - Profile Requester Interaction

  Profile Owner      HTTP                     Profile Requester

request to PR  ---------------------> receive non-IDsec enabled request

set cookie     <--------------------- request for Session Certificate
               Redirect Temporarily (StatusCode 302)
               Set-Cookie: IDSEC=<PRID>#<SID>#CertificateRequest

resend         ---------------------> request indicates non-IDsec client
               Cookie: IDSEC=<PRID>#<SID>#CertificateRequest

data           <--------------------- unadapted response

A.3  Profile Requester - Profile Manager Interaction

  Profile Requester   HTTP                   Profile Manager

request Profile -----------------> verify certificates
                                   (store update URL)
                                   assemble Profile
                request URL found in Session Certificate



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 20]


Internet Draft                    IDsec                         May 2002


                Content-Type: application/idsec
                request data: (update=<update URL>)
                              (&)
                              session_certificiate=<Session Certificate>
                              &
                              requester_certificate=<PR Certificate>

receive Profile <----------------- return XML formatted Profile data
                Content-Type: application/idsec
                response data: XML formatted Profile data

A.4  Profile Manager - Profile Requester Interaction

  Profile Manager   HTTP                   Profile Requester

update Profile -----------------> update profile
                Content-Type: application/idsec
                post data: XML formatted Profile data


Appendix B: Profile DTD

   <!element profile(context*)>
   <!element context((context|attribute)*)>
   <!attlist context
       name CDATA #required
   >
   <!element attribute(value)>
   <!attlist attribute
   <   name CDATA #required
   <
   <!element value(#PCDATA)>

Appendix C: Example Profile Attributes

   An attribute consists of a name and a value. The name is a scoped
   name so name-spacing is supported. The separator character for
   namespaces is ".". The following attributes serve as an illistration
   only.

      Attribute Name                          Attribute Value Type

      private.name.first                      string[255]
      private.name.last                       string[255]
      private.name.initials                   string[255]
      private.address.street.name             string[255]
      private.address.street.number           string[255]
      private.address.zipcode                 string[255]



H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 21]


Internet Draft                    IDsec                         May 2002


      private.telephone                       string[255]

      work.company.name                       string[255]
      work.address.street.name                string[255]
      work.address.street.number              string[255]
      work.address.pobox                      string[255]
      work.address.zipcode                    string[255]
      work.telephone

      billing.creditcard.[n].number           string[255]
                          (n is a number starting from 0)
      billing.creditcard.[n].expirydate       string[255]
                          (n is a number starting from 0)

      other.hobbies                           string[255]
                                   (comma-separated list)
      other.language                          string[255]


































H.Zandbelt, B.Hulsebosch, H.Eertink                            [Page 22]