idnits 2.17.1
draft-zandbelt-idsec-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 2002) is 8016 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '255' is mentioned on line 1024, but not defined
== Unused Reference: '1' is defined on line 838, but no explicit reference
was found in the text
== Unused Reference: '2' is defined on line 841, but no explicit reference
was found in the text
** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Downref: Normative reference to an Historic RFC: RFC 2660 (ref. '4')
** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346)
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC
4248, RFC 4266)
** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2459 (ref. '9') (Obsoleted by RFC 3280)
** Obsolete normative reference: RFC 2510 (ref. '10') (Obsoleted by RFC
4210)
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force H.Zandbelt, B.Hulsebosch, H.Eertink
3 Internet Draft Telematica Instituut
4 draft-zandbelt-idsec-01.txt May 2002
6 IDsec: Virtual Identity on the Internet
8 Status of this Memo
10 This document is an Internet-Draft and is in full conformance with
11 all provisions of Section 10 of RFC2026.
13 Internet-Drafts are working documents of the Internet Engineering
14 Task Force (IETF), its areas, and its working groups. Note that other
15 groups may also distribute working documents as Internet-Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six months
18 and may be updated, replaced, or obsoleted by other documents at any
19 time. It is inappropriate to use Internet-Drafts as reference
20 material or to cite them other than as "work in progress".
22 The list of current Internet-Drafts can be accessed at
23 http://www.ietf.org/ietf/1id-abstracts.txt
25 To view the list Internet-Draft Shadow Directories, see
26 http://www.ietf.org/shadow.html.
28 Abstract
30 IDsec is a mechanism that provides an identity for users on the
31 Internet. Identity in IDsec means that a user is known by a certain
32 profile that contains precisely those attributes that the user wants
33 to reveal to the requester of his profile. Access to profile
34 attributes is managed by the user himself. Certificates and
35 public/private key mechanisms ensure that information is exchanged in
36 a secure way only between parties that trust each other.
38 Table of Contents
40 1. Introduction....................................................2
41 2. Overview........................................................2
42 3. Definitions.....................................................3
43 4. Profiles........................................................4
44 5. Access Control Lists............................................5
45 6. Trusted Certificates............................................6
46 7. Session Certificate.............................................6
47 8. Profile Manager.................................................7
48 9. Profile Owner..................................................10
49 10. Profile Requester..............................................11
50 11. Relationship between Profile Owner and Profile Manager.........12
51 12. Relationship between Profile Requester and Profile Manager.....13
52 13. Relationship between Profile Owner and Profile Requester.......14
53 14. Content Distribution Network Provider..........................14
54 15. Certificate Management.........................................15
55 16. Profile Updates................................................15
56 17. Usage Scenario's...............................................16
57 18. Conclusion.....................................................16
58 19. Security Considerations........................................16
59 20. References.....................................................16
60 21. Author's Addresses.............................................17
61 22. Acknowledgments................................................18
62 Appendix A: Interaction Diagrams...................................18
63 Appendix B: Profile DTD............................................19
64 Appendix C: Example Profile Attributes.............................19
66 1. Introduction
68 Today many services exist on the Internet that require some form of
69 user identification or user information, e.g. for personalisation or
70 e-commerce purposes. These services rely on customer information to
71 improve their quality by using previously acquired knowledge about
72 users stored in user profiles. However each of these services
73 implements its own mechanism for that purpose, wich leads to user
74 information redundancy, fragmentation and possible inconsistency.
75 Moreover the current situation forces users to maintain multiple
76 profiles at multiple service providers. This overload of personal,
77 possibly privacy-sensitive, information floating around the Internet
78 leads to great issues of trust.
80 In this memo we present a generic mechanism for establishing Virtual
81 Identities on the Internet, that standardises protocols and
82 interfaces for exchanging identity information between users and
83 service providers in a secure manner. It enables users to reuse
84 profile information across Internet services and service providers to
85 delegate (part of) their customer information maintenance.
87 2. Overview
89 Profiles are stored with so-called Profile Managers somewhere on the
90 Internet. Profile Managers are parties that have a trusted
91 relationship with the Profile Owners whose Profiles they have stored
92 in their databases.
94 A Profile Manager runs a server application that allows his clients
95 to modify their Profile over a secure connection. In addition to
96 modification of attributes and their values, Profile Owners can
97 assemble Access Control Lists that specify which attributes are
98 accessible to which Profile Requesters. Access Control Lists are
99 based on certificate [9] information.
101 Upon starting an Internet action that requires the use of IDsec, a
102 Profile Owner will login with the Profile Manager. This "session
103 login" will result in the creation of a "session certificate" that is
104 sent to the Owner. The session certificate represents the Owner in
105 the current Internet session and it contains a reference to the
106 location of his Profile.
108 The Profile Owner sends the session certificate to the IDsec enabled
109 Profile Requester. The Requester in his turn, sends it together with
110 his own root certificate to the location specified in the session
111 certificate. The Profile Manager uses the session certificate to
112 identify the Owner and to assemble a Profile Requester specific
113 Profile based on the Requester credentials and the Access Control
114 List that the Owner specified.
116 The Profile Requester now has a customer Profile that he can use to
117 personalize content, to do accounting and/or billing (eventually in
118 combination with a third party) and any other business that he would
119 normally do with locally stored customer data.
121 Notice that IDsec supports "anonymous browsing" and single sign-on;
122 it does not neccesarily reveal the name and address of the Profile
123 Owner or any other attribute that uniquely identifies the Profile
124 Owner. IDsec transmits exactly those attributes that an Owner trusts
125 to be sent to the Requester.
127 3. Definitions
129 Attribute
131 A name-value pair in a Profile.
133 Profile
135 A set of attributes that represents a Profile Owner on the
136 Internet.
138 Profile Owner (or Owner)
140 A role for a party on the Internet that wants Profile Requesters
141 to associate him with a certain Profile.
143 Profile Requester (or Requester)
144 A role for a party on the Internet that wants to associate another
145 party with a Profile.
147 Profile Manager (or Manager)
149 A role for a party on the Internet that stores a Profile for a
150 Profile Owner and makes it accessible for Profile Requesters.
152 4. Profiles
154 A Profile is a data record that contains information about a certain
155 Profile Owner. It represents an Owner and as such it can be helpful
156 in many circumstances on the Internet. In the IDsec system, the
157 information that is typically found in legacy user profiles like
158 name-address type of information, may be extended with information
159 that has a more dynamic, session-oriented nature. Examples are
160 presence related information and terminal related settings.
162 A basic Profile contains vCard-like [11] information such as:
164 Name
165 Address
166 Telephone Number
167 E-mail address
168 Date of birth
170 In addition to that it may contain billing-related information such
171 as:
173 Creditcard data
174 Bank-account data
176 This is expected to be valuable in the e-commerce type of web-
177 services. Furthermore a Profile could contain user preferences such
178 as:
180 Home environment specific data
181 Application specific data
182 Service Provider specific data
184 The IDsec Profile consists of a set of name-value tuples called
185 attributes. The attribute namespace is a directory like hierarchy
186 thus supporting namespaces. A typical attribute example is:
188 "private.address.zipcode"
190 or
191 "billing.creditcard.expirydate".
193 A Profile can be stored in a Manager specific way but it is presented
194 and transferred to Requesters in a simple XML format with the DTD
195 found in Appendix B - Profile DTD. A typical Profile example is:
197
198
199
200
201 7500 AN
202
203
204
205
206
207
208 01/01/2004
209
210
211
212
214 All attributes that can be found in a Profile must be standardized
215 and must therefore be described in standards documentation. However
216 the defined set is expected to be extended on a regular basis. The
217 standard must also specify the type of the value and how it should be
218 interpreted. This document does not attempt to standardize
219 attributes; only example attributes names and their value types have
220 been defined so far. (see Appendix C - Example Profile Attributes).
222 5. Access Control Lists
224 In addition to an attribute value, the Profile Manager also offers
225 the possibility of defining and storing an Access Control List (ACL)
226 for each attribute. An ACL specifies exactly which Requesters have
227 read-access to the attribute value. ACL values are based on
228 information found in a certificate [9] (called Requester certificate)
229 that a Requester has to present to get access to a specific
230 attribute. An Access Control List consists of one or more Access
231 Control Elements (ACE). Each ACE consists of 4 elements:
233 o Distinguished Name
235 This field contains a regular expression that needs to be matched
236 against the Distinguished Name field that is presented in the
237 Requester certificate. In case the Distinguished Name field is
238 empty, the additional name forms that are conveyed in the subject
239 alternative names extension are used [9]. Especially domain names
240 will be used in this context.
242 o Organization
244 This field contains a regular expression that needs to be matched
245 against the Organization field that is presented in the Requester
246 certificate.
248 o Organizational Unit
250 This field contains a regular expression that needs to be matched
251 against the Organizational Unit field that is presented in the
252 Requester certificate.
254 o Issuer
256 This field contains a reference to the root certificate of the
257 Certificate Authority that issued the Requester certificate. This
258 issuer's root certificate is also stored with the Profile Manager
259 so it can be used to validate the signature on the Requester
260 certificate. (see Trusted Certificates)
262 In order to be able to read the attribute value that the ACL is
263 associated with, the Requester must present a certificate that
264 matches one or more of the ACEs in the ACL on all four fields. In
265 other words: ACEs are inclusive: Requester access to the attribute is
266 disabled by default. ACEs are compared one-by-one; when a positive
267 match is found, the search is stopped and access is granted.
269 A special value ACL exists that denotes a so-called "public"
270 attribute, ie. an attribute that is readable by any Requester.
272 A future specification of ACLs might also incorporate certification
273 policy. A Profile Owner could be willing to release certain
274 attributes to any party that holds a certificate issued under a
275 particular policy.
277 6. Trusted Certificates
279 The Profile Manager must offer the possibility of uploading and
280 storing root certificates of Certificate Authorities that are trusted
281 by the Profile Owner. Each Owner can upload his own trusted
282 certificates that have to be used to validate the Requester
283 certificates. In addition to the "personal" trusted certificates, a
284 Profile Manager may predefine a set of root certificates that he
285 considers to be trusted. This would prevent him from storing for
286 example, Verisign root certificates, several times for multiple
287 Profile Owners. Notice that this does not neccesarily mean that an
288 Owner automatically trusts these certificates; he can choose not to
289 use these predefined certificates in his ACLs.
291 7. Session Certificate
293 This certificate identifies the Profile Owner's Internet session in
294 the context of a Profile Manager. The certificate itself does not
295 reveal any information about the Owner; it serves as a pointer to a
296 Profile. The information in the Session Certificate consists of the
297 following components:
299 o Session Identifier
301 The session identifier serves as a pointer to the session,
302 meaningful only in the environment of the Profile Manager where
303 the certificate was created. Although it uniquely identifies a
304 session, and therefore points to a specific Owner, the identifier
305 itself must be constructed in such a way that it does not reveal
306 information about the session or the Owner of the session.
308 o Profile Manager Location
310 This is a reference to the Profile Retrieve Service (see Profile
311 Retrieve Service). This service can be used to retrieve the
312 Profile of the Owner associated with the session certificate
313 (after authentication and authorization of the Requester).
315 o Profile Manager Signature
317 The Session Certificate is signed by the Profile Manager so the
318 integrity of the data in the certificate can be verified by the
319 Profile Manager when it is presented by a Requester for Profile
320 retrieval. In case of a trusted relationship between Profile
321 Requester and Profile Manager (see Relationship between Profile
322 Requester and Profile Manager), the Requester can also check the
323 integrity of the certificate.
325 o Public Key
327 The public key in the Session Certificate is generated by the
328 Profile Owner together with a private key that is stored on his
329 local system. Whenever information needs to be passed in a secure
330 manner from Profile Requester to Profile Owner, the public key can
331 be used by the Requester to encrypt the data. The Owner can use
332 the corresponding private key to decrypt the data.
334 o Expiration Date
335 The Session Certificate contains an expiration date so that the
336 certificate cannot be reused after the specified date. This
337 enables a Manager to manage the amount of (unused) session data in
338 an efficient way.
340 8. Profile Manager
342 The Profile information is stored by a so-called Profile Manager that
343 is trusted by the Profile Owner. Notice that it is possible for a
344 Profile Owner to act as his own Profile Manager (see Profile
345 Management Service). A Profile Manager enables a Profile Owner to
346 manage his Profile and he offers access to Profile information to
347 interested third parties such as Internet Service Providers and
348 Content Distribution Network Providers. Three services must be
349 offered by the Profile Manager:
351 o Profile Management Service
353 This is a service that a Profile Owner can access to manipulate
354 his Profile data. In the case of a Profile Manager operating for
355 multiple Owners, it is likely that all data is stored in a back-
356 end database server. The Profile Management Service is accessed by
357 means of a client application that an Owner can use to manipulate
358 Profile attributes, their values, their ACLs and the stored
359 certificates.
361 Strictly spoken the client application and the communication
362 between Profile Manager and Profile Owner can be Manager specific
363 and needs not to be standardized by this document. One could even
364 operate a so-called Local Profile Manager, implemented as a
365 service running on the Owner machine, where communication is done
366 through function calls to libraries.
368 However, all external communication must be done over a secure
369 encrypted channel. Upon establishing this channel, both parties
370 must be able to verify each other by means of commonly agreed
371 authentication mechanisms. The Owner credentials are possibly, but
372 not necessarily, stored as ordinary (non-externally accessible)
373 Profile attributes. A typical solution would be a HTTPS [4]
374 connectivity where a Profile Manager server certificate must be
375 presented to the Owner when the connection is initiated (see
376 Profile Owner - Profile Management Application).
378 o Session Login Service
380 A Profile Manager runs a Session Login service that provides
381 Session Certificates to Profile Owners. When an Owner successfully
382 logs into this service with Manager specific credentials, a so-
383 called session is established. In addition to credentials, the
384 Owner must also present the public key of a dynamically created
385 public/private keypair. As a result of the login phase a Session
386 Certificate is returned to the Owner (see Session Certificate).
388 Similar to the Profile Management Service, the Session Login
389 service can be implemented in a Manager specific way. However a
390 typical solution would again be a service over an HTTPS connection
391 in which the Profile Manager authenticates himself with a server
392 certificate (see Profile Owner - Session Login Application).
394 o Profile Retrieve Service
396 This is a service that a Profile Requester can access to retrieve
397 a Profile Owner's Profile. The Requester presents a Session
398 Certificate sent by the Owner together with his own Requester
399 certificate to the Profile Retrieve Service in the Profile
400 request. The Profile Retrieve Service verifies the Session
401 Certificate and uses the session identifier to find the Owner that
402 is associated with the session. The Profile Manager verifies the
403 Profile Requester certificate by means of the trusted certificates
404 that the Owner stored with his Profile (see Trusted Certificates).
405 Upon successful verification, a Requester specific Profile is
406 assembled by interpreting the Access Control Lists for each
407 attribute. An XML formatted subset of attributes (see Profiles)
408 is sent in the Profile response to the Requester.
410 The communication channel must be made secure by using
411 public/private key encryption techniques. Several communications
412 channels may be defined that ultimately return an encrypted
413 Profile. The type of channel will be reflected in the Profile
414 Manager location reference that is transferred in the Session
415 Certificate. Two communication channels have been defined so far:
417 1) HTTP
419 A URL [7] of the form "http:///" indicates that the
420 request for a Profile is sent over plain HTTP [3] and that the
421 Profile is returned as a encrypted data in a plain HTTP
422 response. The HTTP request data consists of the Profile
423 Requester certificate, which is checked against the Access
424 Control Lists of the Profile attributes.
426 Notice that this scheme implies that any data that is sent
427 along with the request (possible indications about subsets of
428 Profiles, or Requester specific extensions) is unencrypted. A
429 default request will contain only public data in which case
430 this is not a security problem. The HTTP response data,
431 consisting of the XML formatted Profile (see Profiles) must be
432 encrypted with the public key that is found in the Profile
433 Requester certificate.
435 2) HTTPS
437 A URL [7] of the form "https:///" indicates that
438 the request and the response for a Profile is sent over a HTTPS
439 [4] connection. The HTTPS connection is setup with the Profile
440 Requester certificate as a client certificate and the Profile
441 Manager certificate as the server certificate.
443 Notice that the exchanged certificates cannot be checked by the
444 Profile Manager nor by the Profile Requester because in general
445 they don't have a trusted relationship (see Relationship
446 between Profile Requester and Profile Manager). However we
447 choose for defining an HTTPS communication mechanism since it
448 is a convenient means of secure communication, which meets our
449 demand for encryption. Future extensions of the request format,
450 (for example primitives to ask for a subset of a Profile, or
451 Requester specific data) will perhaps require encryption of the
452 request, which in that case is already covered by HTTPS.
454 3) Local
456 A URL of the form "local://" indicates that the user operates
457 as a so-called Local Profile Manager. In this case the request
458 for a profile can be sent to the Profile Owner over the same
459 communication channel that was used to send the Session
460 Certificate, possibly as a response message. The request data
461 must contain only the Profile Requester certificate as the
462 Session Certificate is known to the Profile Owner already. The
463 Profile data returned by the Owner, will be encrypted with the
464 public key found in the Profile Requester certificate.
466 This protocol is adopted to enable a Profile Owner to operate
467 as a light-weight Profile Manager. Profile Management software
468 may be linked against the client application in this case, so
469 running a separate, possibly heavy-weight, Profile Management
470 Service as a standalone server application is no longer
471 necessary (see also Profile Manager - Profile Management
472 Service).
474 9. Profile Owner
476 At the client side three seperate functionalities can be
477 distinguished:
479 o Profile Management Application
481 Profile maintenance is done by logging into the Profile Management
482 Service (see Profile Manager - Profile Management Service). A
483 client application is used to edit Profile attributes, their
484 values, their ACLs and the stored certificates. Both sides must
485 authenticate each other and a secure communication channel must be
486 established.
488 All components (application, service, authentication and channel)
489 may be Manager specific.
491 Typically a Profile Owner will gain access to the Profile
492 Management Service with a username/password combination and the
493 Profile can be manipulated through a set of HTML [6] pages in a
494 browser over an HTTPS connection. A Profile Manager server
495 certificate will be presented to the Owner who must be able to
496 verify it.
498 o Session Login Application
500 Upon entering an IDsec enabled Internet site, the Profile Owner
501 will be asked for a Session Certificate (see Session Certificate).
502 To receive a Session Certificate, an Owner must log into the
503 Session Login Service (see Session Login Service) with his Manager
504 specific credentials, likely to be the same as he uses for the
505 Profile Management Service (see Profile Management). In addition
506 to that, he needs to generate a public/private keypair and include
507 the public key in the Session Login request. As a result of that
508 action, a Session Certificate will be returned, containing the
509 public key sent in the request and signed by the Profile Manager
510 (see Session Certificate).
512 Similar to the Profile Management Service, the Session Login
513 service can be implemented in a Manager specific manner.
515 Typically an Owner will log into the Session Login Service with a
516 username/password combination over an HTTPS connection where a
517 server certificate will identify the Profile Manager.
519 o Session Certificate Handler
521 At the client side, functionality is needed to extend Internet
522 service requests with Profile related information and to be able
523 to interpret any Profile related responses from IDsec enabled
524 Internet sites. A typical way to offer this functionality is by
525 means of a service specific plugin or a generic Internet proxy.
526 The handler will intercept Session Certificate requests from IDsec
527 enabled sites and it will present the certificate that is
528 retrieved by the Session Login Application. After doing so, a
529 specific Internet request header will be included with every
530 following request that serves as a pointer to the Session
531 Certificate, so that the certificate itself does not need to be
532 passed with every request.
534 When the Profile Requester wishes to verify the Owner of the
535 Session Certificate, he must send challenge data (see Profile
536 Requester - Encryption Handler) that will be answered by the
537 handler, using the private key generated in the Session Login
538 phase. For details the reader is referred to Appendix A -
539 Interaction Diagrams.
541 10. Profile Requester
543 Any party on the Internet, for example an Internet Service Provider,
544 that is interested in the Profile of a user that is accessing his
545 Internet site, can use IDsec software to get access to the Profile
546 attributes; by doing so, he is called a Profile Requester in the
547 IDsec terminology. To that purpose the Profile Requester may use
548 IDsec software suited for use in the specific server environment that
549 he operates. The IDsec library must offer the following
550 functionality:
552 o Session Certificate Request Component
554 The Profile Requester uses this component to intercept any non-
555 IDsec-aware requests that the Owner sends and to ask for a Session
556 Certificate. If a Session Certificate cannot be presented by the
557 Owner (possibly because he is a non-IDsec-aware user), normal
558 operation is resumed, otherwise the Profile Request Component will
559 be used to get access to the Profile data of the Owner associated
560 with the Session Certificate.
562 o Profile Request Component
564 This software component is a client application of the Profile
565 Retrieve Service. It extracts the Profile Manager location
566 reference from the Session Certificate and sends a request for a
567 Profile to that location. The Profile request must contain both
568 the Session Certificate and the Profile Requester certificate (see
569 Profile Retrieve Service).
571 o Encryption Handler
573 A Profile Requester cannot be sure of the identity of the Owner
574 based only on the sending of the Session Certificate. That
575 certificate may have been snooped and (re)used by a malicious
576 user. Therefore he may want to verify that the sender of the
577 Session Certificate is the rightful owner by using the Encryption
578 Handler. It will send challenge data encrypted with the public key
579 in the Session Certificate. Upon a successful response (see
580 Profile Owner - Session Certificate Handler), the Requester can be
581 sure that the session certificate was sent by the party that owns
582 the corresponding private key, thus the owner of the certificate.
584 In general a Profile Requester must encrypt any privacy sensitive
585 data that is sent to the Owner with the Session Certificate public
586 key. For large amounts of data or streaming data, a secure data
587 channel may be established using the Session Certificate public
588 key. A TLS [5] connection is a convenient example.
590 Notice that the trusted relationship between Owner and Requester (see
591 Relationship between Profile Owner and Profile Requester) also
592 implies that the Requester must not send unencrypted content that
593 reveals any access-restricted Profile information about the Owner.
594 For example: a Web Service Provider cannot do content adaptation of
595 HTML pages for Owner Bob saying "Hello Bob", if the attribute
596 containing the name "Bob" is not a public attribute.
598 11. Relationship between Profile Owner and Profile Manager
600 A trusted relationship must exist between an Profile Owner and his
601 Profile Manager.
603 o A Profile Owner must trust the Profile Manager
605 The Owner stores his privacy-sensitive data at the Manager. He
606 trusts the Manager to protect his privacy sensitive data and to
607 enforce the Access Control policies on the Requesters.
609 o A Profile Manager must trust a Profile Owner
611 The Manager has a customer-provider relationship with the Owner.
612 Before accepting an Owner as a customer, the Profile Manager will
613 ensure that the Owner is a trustworthy partner with respect to
614 billing and abuse of the system. A Service Level Agreement may
615 exist between Owner and Manager so that when either the Manager
616 does not meet the quality of service, or the Owner breaks the
617 rules, the contract will be ended.
619 12. Relationship between Profile Requester and Profile Manager
621 A trusted relationship between a Profile Requester and a Profile
622 Manager may exist.
624 o A Profile Manager may not trust a Profile Requester
626 The Profile Requester certificate for the Profile request is used
627 in the communication with the Manager without being trusted by the
628 Manager itself. The certificate, or to be more precisely, the
629 public key is only used to encrypt the Profile data that has to be
630 returned in a secure manner. This ensures that only the rightful
631 owner of the Requester certificate and thus the Owner of the
632 corresponding private key, is able to read the Profile.
634 The Owner himself determines to which level the Profile Requester
635 is trusted and thus which Profile information he is allowed to
636 access. He does so by specifying Access Control Lists and storing
637 trusted certificates. The Profile Retrieve Service verifies
638 certificates on behalf of the Owner because the Owner trusts him
639 to do so (see Relationship between Profile Owner and Profile
640 Manager).
642 o A Profile Requester may not trust a Profile Manager
644 1) Non-Trusted
646 The non-trusted case works similar to current e-commerce web-
647 sites; information that is entered (ie. provided by the Profile
648 Manager), needs to be verified (if needed at all) in some
649 other, possibly non-electronic way. Requester specific
650 credentials or a creditcard number are typical Profile
651 attributes that need verification in this scenario. (see
652 Relationship between Profile Owner and Profile Requester)
654 2) Trusted
656 In the trusted case, a Profile Requester asks for a Profile
657 Manager certificate at the beginning of establishing a
658 communication channel. The certificate is verified by the
659 Requester (see Profile Manager - Profile Retrieve Service -
660 HTTPS). In this scenario, information provided for a specific
661 Owner needs not to be verified. The Manager guarantees the
662 correctness of information and the identity of the Owner. The
663 party that signed the Profile Manager certificate could be an
664 organization that issues certficates to trusted Profile
665 Managers, a so-called Profile Manager Root Certificate
666 Authority.
668 The trusted model may seem to be attractive at first glance, but
669 we have to keep in mind that a large number of Profile Managers
670 may exist (up to private ones). Moreover this scenario is only
671 interesting when there is no prior established relationship
672 between Owner and Requester, but there is one already between
673 Manager and Requester.
675 The bottom line in both cases is that the information returned by
676 the Profile Manager can be used to authenticate the Owner that is
677 associated with the Session Certificate.
679 13. Relationship between Profile Owner and Profile Requester
681 A trusted relationship between an Profile Owner and a Profile
682 Requester may exist.
684 o A Profile Owner may trust a Profile Requester
686 An Owner specifies Access Control Lists that specify to exactly
687 which attributes a Requester may access (see Access Control Lists)
688 in addition to the so-called "public" attributes. In the case of
689 non-public attributes, the Owner trusts the Profile Requester with
690 the information: he assumes that his private information is
691 securely kept within the Requester domain.
693 o A Profile Requester may trust a Profile Owner
695 The Requester trusts an Owner based on, possibly Requester
696 specific, information found in the Profile and only after
697 verifying the Owner of the Session Certificate (see Profile
698 Requester - Encryption Handler).
700 An alternative to requester specific credentials can be the use of
701 a trusted-third-party. This would be a well-known party trusted by
702 both the Profile Requester and the Profile Owner. If the Profile
703 Owner is able to present credentials that can only have been
704 issued by the trusted-third-party, the Profile Requester may
705 decide to trust the provided Profile data without additional
706 checks. The validity of the data would be ensured by the trusted-
707 third-party in that case.
709 14. Content Distribution Network Provider
711 An Internet Service Provider may wish to delegate the tasks of
712 content hosting and content adaptation to a Content Distribution
713 Network Provider (CDN Provider). A CDN Provider can perform these
714 tasks for several Service Providers in an optimized way. In order to
715 be able to adapt content on behalf of a Service Provider, the CDN
716 Provider needs to get access to the Profile data that the origin
717 Service Provider is allowed to access. He needs Service Provider
718 specific credentials to do so.
720 We foresee a solution in which a CDN Provider can use a certificate
721 that is signed by the Service Provider to access the Profile data.
722 The Profile Manager checks the signature on the certificate against
723 Access Control Lists that the Owner has specified for his Profile
724 attributes. In that way a CDN Provider is able to act as a Profile
725 Requester on behalf of a Service Provider.
727 15. Certificate Management
729 In the IDsec environment, all certificate management is done by
730 "traditional" certificate authorities (see also [10]). Profile
731 Requesters need to get a certificate signed by a certificate
732 authority. The only exception to this are certificates that a CDN
733 Provider may use on behalf of a Service Provider (see Content
734 Distribution Network Provider). These certificates have to be signed
735 by Service Providers.
737 Notice that there is no need for Session Certificate management, as
738 all session certificates have a limited usage period. They will
739 expire automatically so no certificate revoke lists are needed. The
740 Profile Manager can deal with comprimised sessions or malicious users
741 by using session- and user-management only.
743 16. Profile Updates
745 As stated before, Profile data may have a dynamic nature (see
746 Profiles). Examples of such data are presence related information and
747 terminal related settings (audio on/off). This brings up the issue of
748 Profile update propagation: how to notify interested parties when a
749 Profile changes? We define a subscription mechanism to deal with
750 Profile updates. A Profile Requester may subscribe to Profile
751 attribute updates by indicating this in the Profile request that he
752 sends to the Profile Manager. The request must contain a URI [8] that
753 points to a handler that is able to process Profile updates that a
754 Manager sends. The Manager manages the subscriber list. We define two
755 levels of granularity:
757 o Full
759 A full subscriber receives a complete Profile with the latest
760 attribute values upon every update of a Profile. This level is
761 convenient for less frequent updates; it can easily be implemented
762 by reusing the code that handles a normal Profile response.
764 o Partial
766 A partial subscriber indicates in which Profile attributes he is
767 interested. He will receive an update when such an attribute
768 changes and the update contains the single new attribute value
769 only. This level is convenient for frequently updated attributes.
771 The layout of the update interfaces can be found in Appendix A.
773 17. Usage Scenario's
775 One can think of many scenario's on the Internet where the use of
776 secure Profiles as offered by IDsec can bring added value. We would
777 like to describe two of them here which we consider to be among the
778 more important ones:
780 o Content personalisation while browsing anonymously
782 Because IDsec supports a fine granularity of access control to
783 Profile attributes, it is possible to restrict access to
784 name/address information while offering access to information that
785 does not uniquely identify a person. This enables Profile
786 Requesters such as Web Service Providers to do content
787 personalisation based on, for example, hobbies or favourite color
788 whithout forcing the user to reveal his actual identity.
790 o Third party billing
792 Accounting, payment and billing can be done in a secure manner by
793 relaying it to a trusted third party indicated in the Profile.
794 Creditcard data won't be passed to Service Providers but merely to
795 a billing party trusted by the Service Provider that also has
796 access to the creditcard data in the Profile.
798 18. Conclusion
800 IDsec forms a simple application level solution for establishing
801 Virtual Identities on the Internet; it is flexible and extensible. We
802 constructed a solution with standard off-the-self components and
803 protocols such as HTTP, HTTPS and certificates. IDsec offers support
804 for anonymous browsing, single-signon and Profile extensibility. The
805 specification does not fix transport protocols or security
806 interfaces; it is setup in a modular fashion so improvements can be
807 plugged in.
809 19. Security Considerations
811 A main concern for digital identity systems that use a remote
812 location for storing data is that users must find a trusted party
813 that is able and willing to operate this service for them. As this
814 party will have access to all of a persons private data this is a
815 crucial issue and choices must be made with care. As it is a risk to
816 put all of a persons data with just one Profile Manager, we foresee
817 that people will manage multiple identities and thus spread their
818 private data across multiple Profile Managers (ie. work, home,
819 sports, hobbies).
821 A Profile Manager must be able to protect the privacy of the customer
822 at all times. As one Profile Manager is likely to store data for
823 multiple customers, it is an attractive target for hackers and
824 malicous organizations. System level security is crucial here.
826 Furthermore users must realize that they influence the security of
827 their data themselves when providing access to Profile Requesters.
828 How can one be sure to trust a Profile Requester? That is the key
829 question and this memo cannot present a solution for that. If a by
830 any mistake, a malicous Profile Requester is granted access, a
831 sensitive data leak will have been created; the mistake can be
832 corrected but the damage will have been done. No identity system can
833 take responsibility for a users actions nor can it guarantee
834 correctness of those actions.
836 20. References
838 [1] Bradner, S, "Key words for use in RFCs to Indicate Requirement
839 Levels", RFC 2119, BCP 14, March 1997.
841 [2] Bradner, S, "The Internet Standards Process - Revision 3", RFC
842 2026, March 1997.
844 [3] Gettys, R, Mogul, J, Frystyk, J, Masinter, H, Leach, L,
845 Berners-Lee, P and T Berners-Lee, "Hypertext Transfer Protocol
846 - HTTP/1.1", RFC 2616, June 1999.
848 [4] E. Rescorla, "The Secure HyperText Transfer Protocol",
849 RFC 2660, August 1999.
851 [5] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
852 January 1999.
854 [6] Raggett, D., "HTML 3.2 Reference Specification", W3C
855 Recommendation, January 1997.
856 Available at .
858 [7] Berners-Lee, T., Masinter L., and M. McCahill,
859 "Uniform Resource Locators (URL)", RFC 1738, December 1994.
861 [8] Berners-Lee, T, Fielding, R, Irvine, U C and L Masinter,
862 "Uniform Resource Identifiers (URI): Generic Syntax", RFC
863 2396, August 1998.
865 [9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
866 Public Key Infrastructure, Certificate and CRL Profile", RFC
867 2459, January 1999.
869 [10] Adams, C. and S. Farrell, "Internet X.509 Public Key
870 Infrastructure, Certificate Management Protocols", RFC
871 2510, March 1999.
873 [11] Internet Mail Consortium, "vCard - The Electronic
874 Business Card Version 2.1",
875 http://www.imc.org/pdi/vcard-21.txt, September 18, 1996.
877 21. Author's Addresses
879 Hans Zandbelt
880 Telematica Instituut
881 Drienerlolaan 5
882 7500 AN Enschede
883 Netherlands
885 Phone: +31 53 4850 445
886 EMail: hans.zandbelt@telin.nl
888 Bob Hulsebosch
889 Telematica Instituut
890 Drienerlolaan 5
891 7500 AN Enschede
892 Netherlands
894 Phone: +31 53 4850 498
895 EMail: bob.hulsebosch@telin.nl
897 Henk Eertink
898 Telematica Instituut
899 Drienerlolaan 5
900 7500 AN Enschede
901 Netherlands
903 Phone: +31 53 4850 409
904 EMail: henk.eertink@telin.nl
906 22. Acknowledgments
908 Thanks to Martin Wibbels and Stanislav Pokraev of Telematica
909 Instituut for their contributions. Also thanks to the people on the
910 DotGNU Auth mailing list for their suggestions, especially David
911 Sugar. Other valuable feedback has been provided by Russ Housley.
913 Appendix A: HTTP Interaction Diagrams
915 Legenda: ----> = HTTP request
916 <---- = HTTP response
917 PR = Profile Requester
918 SC = Session Certificate
919 = Profile Requester specific identifier
920 = Profile Requester specific session identifier
922 A.1 Profile Owner - Profile Requester Interaction
924 Profile Owner HTTP Profile Requester
926 request to PR ---------------------> receive non-IDsec enabled request
928 request for SC <--------------------- request for Session Certificate
929 Redirect Temporarily (StatusCode 302)
930 Set-Cookie: IDSEC=##CertificateRequest
932 send SC ---------------------> retrieve the Profile
933 Cookie: IDSEC=##CertificateResponse
934 request data:
936 adapted data <--------------------- interpret Profile and adapt
938 A.2 Profile Owner (non-IDsec-enabled) - Profile Requester Interaction
940 Profile Owner HTTP Profile Requester
942 request to PR ---------------------> receive non-IDsec enabled request
944 set cookie <--------------------- request for Session Certificate
945 Redirect Temporarily (StatusCode 302)
946 Set-Cookie: IDSEC=##CertificateRequest
948 resend ---------------------> request indicates non-IDsec client
949 Cookie: IDSEC=##CertificateRequest
951 data <--------------------- unadapted response
953 A.3 Profile Requester - Profile Manager Interaction
955 Profile Requester HTTP Profile Manager
957 request Profile -----------------> verify certificates
958 (store update URL)
959 assemble Profile
960 request URL found in Session Certificate
961 Content-Type: application/idsec
962 request data: (update=)
963 (&)
964 session_certificiate=
965 &
966 requester_certificate=
968 receive Profile <----------------- return XML formatted Profile data
969 Content-Type: application/idsec
970 response data: XML formatted Profile data
972 A.4 Profile Manager - Profile Requester Interaction
974 Profile Manager HTTP Profile Requester
976 update Profile -----------------> update profile
977 Content-Type: application/idsec
978 post data: XML formatted Profile data
980 Appendix B: Profile DTD
982
983
984
987
988
993 Appendix C: Example Profile Attributes
995 An attribute consists of a name and a value. The name is a scoped
996 name so name-spacing is supported. The separator character for
997 namespaces is ".". The following attributes serve as an illistration
998 only.
1000 Attribute Name Attribute Value Type
1002 private.name.first string[255]
1003 private.name.last string[255]
1004 private.name.initials string[255]
1005 private.address.street.name string[255]
1006 private.address.street.number string[255]
1007 private.address.zipcode string[255]
1008 private.telephone string[255]
1010 work.company.name string[255]
1011 work.address.street.name string[255]
1012 work.address.street.number string[255]
1013 work.address.pobox string[255]
1014 work.address.zipcode string[255]
1015 work.telephone
1017 billing.creditcard.[n].number string[255]
1018 (n is a number starting from 0)
1019 billing.creditcard.[n].expirydate string[255]
1020 (n is a number starting from 0)
1022 other.hobbies string[255]
1023 (comma-separated list)
1024 other.language string[255]