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]