Digital Identity Exchange

Beth has many computing environments in her life, running different=20=20 operating systems and different application software. She makes her own choices about her own computing environment, but=20=20 she has little choice when the software is within a device or when=20=20 she's at work, where she is subject to her employer's policies. A consequence is that she uses multiple Identity Agents, which she=20=20 uses for managing different personas. The first two sentences are just motivation... the last line is the=20=20 important statement. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Apr 12 17:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTmWR-0003nd-M7; Wed, 12 Apr 2006 17:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTmWQ-0003nY-Ix for dix@ietf.org; Wed, 12 Apr 2006 17:05:06 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTmWQ-00087y-6y for dix@ietf.org; Wed, 12 Apr 2006 17:05:06 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 41A30142277 for ; Wed, 12 Apr 2006 14:05:05 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05194-01 for ; Wed, 12 Apr 2006 14:05:04 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E8BB14226E for ; Wed, 12 Apr 2006 14:05:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References:

Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3322896C-F52B-490C-8813-D0686B25E621@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Wed, 12 Apr 2006 14:04:58 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mar 24, 2006, at 12:57 PM, RL 'Bob' Morgan wrote: > >> FYI: Yadis and LID were explicitly designed to be usable by >> software that doesn't have a GUI, and OpenID can be used that way >> as well. > > Another thing that might be said here is that there's nothing in > the SAML web browser profiles that requires a UI either. Though > the fact that identity-provider discovery is not covered in those > profiles (except for the Common Domain Cookie approach which is not > broadly applicable) does mean that in some deployments (not all by > any means) a UI is used to do discovery. The YADIS discovery > method could well be used to initiate a SAML web browser profile > flow too (and I think some people might even be working on how to > do this). > > But the SAML browser profiles do require browser features that tend > not to be found in other HTTP user agents, or to put it in more of > standards way, are not required to be in them for compliance with > the HTTP-based spec they are implementing. It is my impression > that these specs (eg WebDAV) aren't actually very specific about > which HTTP user agent features are mandatory (though I could be > wrong about that), which if true may need fixing. In the next version of WebDAV (just went through WG last call recently so maybe it's almost done), we attempt to be more specific about which HTTP features are mandatory, though some of our discussions were inconclusive so we didn't add more restrictions in every case. Related to authentication, we required Digest support even in RFC2518, so that didn't change. There wouldn't be much of a chance at all to require HTML or forms support -- which isn't even required of browsers. Heh. Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Apr 13 00:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTtsc-0000ZP-L4; Thu, 13 Apr 2006 00:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTtsb-0000Yd-Vn for dix@ietf.org; Thu, 13 Apr 2006 00:56:29 -0400 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTtsa-0005Sk-Jj for dix@ietf.org; Thu, 13 Apr 2006 00:56:29 -0400 Received: from [192.168.1.2] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Thu, 13 Apr 2006 05:56:11 +0100 Message-ID: <443DDA2C.1030709@novell.com> Date: Thu, 13 Apr 2006 10:27:16 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Digital Identity Exchange , merrells@sxip.com Subject: Re: [dix] draft-merrells-use-cases-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org John, John Merrells wrote the following on 04/10/2006 11:46 PM: > Based on feedback and contributed text I've revised the > draft use cases document. > > Added: > > 1) More browser based use cases. In particular many examples of 'claims'. > 2) Rob and Lisa's non-bowser based use cases. > 3) Brief introductory section on goals of the group. > > Further comments / contributions are most welcome. It was a good idea to have a use cases document. It makes things clearer for the ongoing discussions. I have few clarifications/comments on the use cases.. B12 - Where does the agent live? B8 states that the agent is integrated to Operating system. If so, can we expect the agent will be available even in a computer in the internet caf'e? ( or Is it left to the implementation of the agent? ). Where does the agent get Beths identity data? Is it stored remote or something that she can carry around with her? If so, how does she transfer it to the agent? ( usb, smartcard or something simiar? Is it again implementation specific? ) B17. A mention of how identity agent can be administered will be good. For eg. how does she inform the agent if she switches the insurance provider? B19. This is use case suggests that the identity data may be stored remote so that any device can retrieve the data. The same adds a constraint that user needs to have access to online identity data always. This may be difficult if the agent is expected to acquire the claim and present to local applications in her computer ( for eg. local mails ) while she is not connected through her ISP. B27&B28. Not very clear on what we are trying to convey here in the context of identity agent. It appears to be the current problem if the site doesn't store a cookie when Adam visited first time.. ( I may be missing something. ) Thanks --jaimon _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Apr 13 13:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Uh-0008Dq-QH; Thu, 13 Apr 2006 13:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Uh-0008Dl-7w for dix@ietf.org; Thu, 13 Apr 2006 13:20:35 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Ug-0003wG-TG for dix@ietf.org; Thu, 13 Apr 2006 13:20:35 -0400 Received: from [192.168.6.212] (dhcp212.sxip.com [192.168.6.212]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k3DHKXGd037906 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Apr 2006 10:20:33 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: <443DDA2C.1030709@novell.com> References: <443DDA2C.1030709@novell.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76B59567-BB64-4685-9FB6-572D5D44AE34@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-use-cases-01 Date: Thu, 13 Apr 2006 10:20:33 -0700 To: jjaimon@novell.com X-Mailer: Apple Mail (2.749.3) X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Thanks for your comments. On 12-Apr-06, at 9:57 PM, Jaimon Jose wrote: > I have few clarifications/comments on the use cases.. > B12 - Where does the agent live? B8 states that the agent is > integrated > to Operating system. If so, can we expect the agent will be available > even in a computer in the internet caf'e? ( or Is it left to the > implementation of the agent? ). > Where does the agent get Beths identity data? Is it stored remote or > something that she can carry around with her? If so, how does she > transfer it to the agent? ( usb, smartcard or something simiar? Is it > again implementation specific? ) That's all implementation specific stuff. An identity agent could be a service in the sky, on her computer, on a device she carries about with her or where ever. > B17. A mention of how identity agent can be administered will be > good. > For eg. how does she inform the agent if she switches the insurance > provider? That's implementation specific too. I nice identity agent would make Beth's life as easy as possible. In the use case I'm trying to get over the idea that a membersite can request a claim that Beth does not have and she has to acquire one from somewhere. > B19. This is use case suggests that the identity data may be stored > remote so that any device can retrieve the data. The same adds a > constraint that user needs to have access to online identity data > always. This may be difficult if the agent is expected to acquire the > claim and present to local applications in her computer ( for eg. > local > mails ) while she is not connected through her ISP. Again implementation specific. Beth's phone could access the remote data or the data could be local, or both. Beth could have sync'd her phone before she left the office so has a local snapshot of her identity data. > B27&B28. Not very clear on what we are trying to convey here in the > context of identity agent. It appears to be the current problem if > the > site doesn't store a cookie when Adam visited first time.. ( I may be > missing something. ) B27 and B28 motivate the design of claims, rather than an identity agent. All your questions seem to be from the viewpoint of how would one design and build an identity agent. That's not what these use cases were written to address. What we need to standardize is the protocol that the parties talk and to some extend the format of the stuff that's moved between them. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Apr 18 00:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVhl0-0002Yv-2Z; Tue, 18 Apr 2006 00:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVhhj-0001QC-GY for dix@ietf.org; Tue, 18 Apr 2006 00:20:43 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVhhg-0002NV-7m for dix@ietf.org; Tue, 18 Apr 2006 00:20:43 -0400 Received: from [192.168.1.66] (adsl-69-106-251-0.dsl.pltn13.pacbell.net [69.106.251.0]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k3I4KUdT096790 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 17 Apr 2006 21:20:30 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v749.3) To: Digital Identity Exchange Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-11--476896285 From: John Merrells Date: Mon, 17 Apr 2006 21:20:28 -0700 X-Mailer: Apple Mail (2.749.3) X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,URIBL_OB_SURBL,URIBL_SBL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9e853307a9b954b689e7e27ead420458 X-Mailman-Approved-At: Tue, 18 Apr 2006 00:24:04 -0400 Subject: [dix] draft-merrells-use-cases-02 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org --Apple-Mail-11--476896285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here's an update to the use cases draft that incorporates the comments on the list over the past week. John --Apple-Mail-11--476896285 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name="draft-merrells-use-cases-02.html" Content-Disposition: attachment; filename=draft-merrells-use-cases-02.html Digital Identity Exchange - Use Cases

TOC

Network Working Group	J. Merrells
Internet-Draft	Sxip Identity
Expires: September 2, 2006	March 2006

Digital Identity Exchange - Use Cases

draft-merrells-use-cases-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 2, 2006.

Copyright Notice

Abstract

This document describes the motivating use cases for DIX, the Digital Identity Exchange protocol.

1. Requirements notation
2. Introduction
3. Goals
4. Definitions
5. Browser Based Use Cases
    5.1. B1
    5.2. B2
    5.3. B3
    5.4. B4
    5.5. B5
    5.6. B6
    5.7. B7
    5.8. B8
    5.9. B9
    5.10. B10
    5.11. B11
    5.12. B12
    5.13. B13
    5.14. B14
    5.15. B15
    5.16. B16
    5.17. B17
    5.18. B18
    5.19. B19
    5.20. B20
    5.21. B21
    5.22. B22
    5.23. B23
    5.24. B24
    5.25. B25
    5.26. B26
    5.27. B27
    5.28. B28
    5.29. B29
    5.30. B30
    5.31. B31
    5.32. B32
    5.33. B33
    5.34. B34
6. Non Browser Based Use Cases
    6.1. NB1 - REST
    6.2. NB2
    6.3. NB3 - WebDAV
    6.4. NB4 - AtomPub
    6.5. NB5 - XCAP and SIMPLE
    6.6. NB6 - CalDAV
    6.7. NB7 - IMAP/POP3 and CalDAV
    6.8. NB8 - RSS, Web, and CalDAV
7. Acknowledgements
8. Security Considerations
9. References
§ Author's Address
§ Intellectual Property and Copyright Statements

TOC

1. Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

TOC

2. Introduction

The use cases below describe various scenarios for the Digital Identity Exchnage (DIX) protocol [dmd1] (Merrells, J., “draft-merrells-dix-01.txt,” March 2006.).

TOC

3. Goals

The goals of the protocol are:

Identity Information Exchange:

The primary goal of any DIX protocol is to automate the exchange of Identity Information over the Internet.

Ease of Adoption:

Any DIX protocol must provide the lowest possible barriers to adoption to ensure wide-spread usage of the protocol.

Internet Scale:

Any DIX protocol must provide an Internet scale solution to identity information exchange.

Privacy:

Any DIX protocol must ensure that all aspects of user privacy can be maintained.

TOC

4. Definitions

The following terms and their definitions are drawn from the lexicon of 'The Identity gang', a community of thought leaders in the user-centric digital identity space. [identitygang] (The Identity Gang, “http://identitygang.org/Lexicon,” March 2006.).

Digital Identity - The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more other Parties.

Identity Agent - An agent acting on behalf of the user.

Identifier - An identifying attribute for a set of attributes.

Identity Data / Identity Information - A set of attributes.

Claim - An assertion made by a Claimant of the value or values of one or more attributes of a Digital Subject, typically an assertion which is disputed or in doubt.

TOC

5. Browser Based Use Cases

Some use cases are dependent upon others, so should be perused in order. Beth is our protagonist throughout; a typical Internet user, but she's a bit of a geek.

TOC

5.1. B1

Beth receives an email from a friend introducing her to a new website, geeknews.com, a techie news site. She wishes to sign up so that she can read some articles. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geeknews.com is requesting some data, her first name. She enters 'Beth' at the prompt, provides consent and the data is sent to the site.

TOC

5.2. B2

Beth browses to geekdate.com, she clicks an IN button. Her identity agent informs her that geekdate.com is requesting some data, her first name. Her agent already has this data. She provides consent and the data is sent to the site.

TOC

5.3. B3

Beth decides to create a profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an identifier. She provides consent and the identifier and identifier verification data is sent to the site. Geekdate.com uses the verification data to verify that Beth owns the identifier her agent provided.

TOC

5.4. B4

Beth decides to create a new profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an Identifier. She instructs her identity agent to create an identifier specific to her relationship with geekdate.com. She provides consent and the data is sent to the site.

TOC

5.5. B5

Beth decides to flesh out her profile at geekdate.com. Geekdate.com displays a registration form. One field requests a URL of a photo of her. Beside it is a SAVE button. She enters the URL and clicks the button. Her identity agent displays a screen informing her that this data item can be stored. She decides that she wants to be able to provide that data to other sites. She provides consent and the data is stored by her agent.

TOC

5.6. B6

Geeknews.com offers Beth the option to build up a readership preferences profile over time, the benefit being that the site will tailor its content to her interests. She decides to take up the offer, she sees an IN button, which she clicks. Her identity agent informs her that geeknews.com is requesting some data, an Identifier. She selects an existing identifier that represents a subset of her identity, which is used for a subset of the sites she has a relationship with. She provides consent and the data is sent to the site.

TOC

5.7. B7

Beth wants to have multiple identifiers, for different aspects of herself, her personas. She wants to have a 'home' persona for identity data that she releases to her personal sites, such as geeknews.com. She wants to have a separate 'work' persona for identity data that she releases to work-related sites, such as helpdesk.com. She wants some of her identity data to be the same for her different personas, and other data to be different.

TOC

5.8. B8

[Assumptions: Beth has visited geeknews and geekdate before and has informed her identity agent that she consents to a relationship with them.] Beth starts her day with a strong coffee and a perusal of geeknews.com. She starts her computer and authenticates herself to the operating system. By that authentication mechanism she has also authenticated herself to her identity agent, as her vendor of that system has hooked it into the operating system's authentication system. She browses to geeknews.com and clicks the IN button and is directly shown the content, no further clicks. She then browses to geekdate.com, she clicks the IN button and is directly presented with her profile no further clicks.

TOC

5.9. B9

Beth's identity agent prompts her to provide a 'spoken name'. Using the multimedia capabilities of her computer she records her spoken name; an mp3 of her saying 'Beth'. She later browses to voicebox.com, which runs a voicemail service, she opts to create an account and the site requests some properties, amongst which is a request for her spoken name. She provides consent and the data is sent to the site.

TOC

5.10. B10

Beth purchases a book from an online store, as she's checking out the store makes her an offer: 10% off for completion of a demographic survey. She's tempted, but how many data fields are there? One hundred! Too many to be worth the effort. But it happens to be commonly requested data, which she has already entered during previous exchanges with other sites. So, she completes the remaining fields, saving them to her identity agent for future reuse. She provides consent and the data is sent to the site.

TOC

5.11. B11

Beth has invested significant effort in building up a persona and reputation around a specific identifier, her 'home' identifier. But, she has become dissatisfied with her identity agent and so decides to switch vendors. She establishes a new agent and migrates her identity data from the old one to the new one. She then delegates authority for her identifier to her new identity agent for authentication and provision of identity data.

TOC

5.12. B12

Whilst in town Beth stops off at an Internet Cafe to check her email. She goes to her webmail account, which requires that she identity herself. Her Identity Agent prompts her for consent and provides her identifier so that she can gain access to her email.

TOC

5.13. B13

Beth visits a website to purchase some books. The site requests some identity information, her shipping address. Her Identity Agent warns her that satisfying the request would contravene her established privacy policy. The website wishes to pass her address to affiliated companies so that they may send her valuable promotional offers, but Beth has a privacy policy that not allow unsolicited mail to be sent to her shipping address.

TOC

5.14. B14

Beth moves house, so she changes the home address information stored by her Identity Agent. Her Identity Agent offers to notify all relying parties to whom she has previously provided her home address.

TOC

5.15. B15

Beth is a frequent traveler on Galactic Air, whose site offers a claim of membership for use at affiliate sites. She acquires a membership claim, which her Identity Agent stores for her.

TOC

5.16. B16

Beth visits a Galactic Air affiliate site that provides discounted travel insurance for frequent travelers. She presents her Galactic Air membership claim from her Identity Agent and receives a discount.

TOC

5.17. B17

Beth visits a rental cars site. She opts out of the offered drivers insurance as she is covered by her travel insurance. To complete the booking the site requests a claim that she has valid insurance. Her identity agent is unable to satisfy the request so provides a list of suggested sources. Beth picks her insurance provider and her identity agent acquires the required claim and presents it to the rental car site.

TOC

5.18. B18

A couple of months later Beth books another trip. The travel site requests her claim of Galactic Air membership. Her identity agent finds that the claim has expired, so refreshes it by requesting an updated claim from galacticair.com.

TOC

5.19. B19

Beth leaves work and goes to the bus stop. Whilst waiting for the next bus home she uses her smart phone to browse geeknews.com. Her Identity Agent provides her with the same ease of browsing that she experiences on her work and home computers.

TOC

5.20. B20

Beth is ending her day at work. She leaves work and waits for the next bus home. Her friend calls and invites her to the movies. She uses her phone to browse to the movies.com to find out what's playing. The site requests her current location, which she consents to release via her Identity Agent.

TOC

5.21. B21

Beth signs up with a financial services site, BigPicture.com, which provides an aggregate view of her finances. To provide its service BigPicture.com requires access to her existing bank accounts. Beth wishes to securely provide agency rights to BigPicture.com, so she acquires the appropriate access tokens from her existing bank account providers and stores them with her Identity Agent. She then presents the access tokens to BigPicture.com so that it can access her account data.

TOC

5.22. B22

Beth goes to an auction side, ibay.com. Her Identity Agent shows a signed graphic of ibay.com for releasing data. Beth knows that she's dealing with ibay.com, and not an impostor.

TOC

5.23. B23

Beth visits her online bank, which requires the use of a strong authentication mechanism. She authenticates to her Identity Agent using a two-factor device indicated by the bank to be an acceptable mechanism.

TOC

5.24. B24

Adam uses a service to acquire a verified email claim. With it he can prove that he owns his email address, Adam@example.com, without having to go through a verification process.

TOC

5.25. B25

Beth gives her friend, Adam@example.com, access to her photos. Adam receives an email from Beth inviting him to view her photos. He goes to the site, which requests a verified email claim. He presents his claim and gains access to the photos Beth has published for him.

TOC

5.26. B26

Adam decides to create a profile at geekdate.com. geekdate.com requests an Identifier. He instructs his identity agent to create an identifier specific to his relationship with geekdate.com.

TOC

5.27. B27

Adam visits a site that requires that he prove he is over 21. He provides the site with a claim that he is over 21, issues by the government of his country of residence, gov.ca. The claim contains no other information about Adam and the site is unable to use the claim to discover more information about Adam.

TOC

5.28. B28

Adam returns to the same site. He must again prove that he is over 21. He provides a claim, but the site cannot tell that it is Adam that has returned again to the site.

TOC

5.29. B29

Adam heavily frequents two gambling sites, goldenslots.com and luckydice.com. He uses the same identifier across both sites as he wants them to know he is the same person.

TOC

5.30. B30

Beth provides a claim from galacticair.com to many different websites. She wants all of the sites to know that she is the same person providing the claim, so she can receive a free flight at the end of the year.

TOC

5.31. B31

Beth's employer has partnered with a local university to provide it's staff with access to online courses. She signs up for some modules at the university admissions website acquiring an enrollment claim. She then browses to the computer science school website to sign up for an advanced programming course. The site requests claims that she is an employee, that she has previously completed some basic introductory modules, and that she has been enrolled.

TOC

5.32. B32

Beth is shopping online for a new laptop computer. She visits an online site that caters to recently graduated professionals. She selects a machine and investigates the lease options available. To work out the monthly payment the site requests some claims: A claim that she's an alumni of a university, so that the site can include an appropriately branded tote bag. A claim that she's a member of Galactic Air, so that she can be credited with airmiles for her purchase. And, a claim from a credit scoring agency that she has a 'good' credit rating.

TOC

5.33. B33

Beth is at home checking her work email, she has an email from a colleague assigning a customer support issue to her. The company help desk system is provided by helpdesk.com, an on-demand application provider. She clicks through a link in the email to the page that describes the issue. Helpdesk.com requests a claim that Beth is an employee of 'Nano Software Inc', which she provides from her Identity Agent, and she gains access to the page.

TOC

5.34. B34

Beth has many computing devices in her life, running different operating systems and different application software. She makes her own choices about her own computing environment, but she has little choice when the software is bundled by the device manufacturer or at work where she is subject to her employer's policies. A consequence is that she has multiple Identity Agents, which she uses for managing different personas.

TOC

6. Non Browser Based Use Cases

TOC

6.1. NB1 - REST

Beth wants to use QOPO.com for printing her pictures that are stored in flackr. She visits QOPO.com and her identity agent is instructed to acquire a token from flackr. Her Identity Agent retrieves the token from flackr and presents it to QOPO.com. QOPO.com passes the token over the REST based web service that flackr provides to retrieve her photos for printing.

TOC

6.2. NB2

Beth is a big fan of Rocky Gervas and listens to his podcast fanatically. The Rocky Gervas show recently started charging a small fee for the podcast. Her media player polls the podcast periodically. When polled the site requests a claim from Beth's Identity Agent asserting that Beth has paid for the podcast. Beth's Identity Agent retrieves the claim presents it to the site and the latest episode of The Rocky Gervas show is downloaded.

TOC

6.3. NB3 - WebDAV

At work Beth uses her website editing software (a WebDAV client) to publish some company confidential content to their extranet. Beth is collaborating with Charles at another company, who requires access to the content. Beth configures the extranet to allow Charles access. Charles uses his website editing software (also a WebDAV client) to fetch the content. The extranet site requests identity information, which his client presents from his Identity agent, and he is able to edit the content.

TOC

6.4. NB4 - AtomPub

Beth uses a blogging client (AtomPub) to both post content to her blog and to add comments on other people's blog postings. Her client uses her identity agent to associate identifying information (her blog url and favicon) with her comments.

TOC

6.5. NB5 - XCAP and SIMPLE

Beth uses her instant messaging client (a SIMPLE client) to communicate with her friends. She uses her client to update her profile information (via XCAP), adding a new friend. Her client didn't need to authenticate to her XCAP server, as she had already authenticated herself to her identity agent.

TOC

6.6. NB6 - CalDAV

Beth needs to arrange a conference call with Charles. She uses her calendaring software (a CalDAV client) to publish her free-busy time to Charles. Charles uses his calendaring software (also a CalDAV client) to fetch Beth's free-busy time. Beth's calendar publisher requests some identity information of Charle's client. It's provided from his identity agent and he is able to book a time for the call.

TOC

6.7. NB7 - IMAP/POP3 and CalDAV

At work Beth uses both calendaring (CalDAV) and email (IMAP,POP3,SMTP) clients to manage her time and messages. Her identity agent authenticates her as owning the identifier that both clients use to identify her. In this way she need only authenticate once to her identity agent instead of twice, once to each client.

TOC

6.8. NB8 - RSS, Web, and CalDAV

Beth works in a distributed workgroup collaborating with colleagues, individual contractors, and employees of partner companies. The calendaring information she has access to is available via CalDAV, RSS, and HTTP/HTML. Each of her software clients uses her identity agent to ensure she need only authenticate once, instead of once per client.

TOC

7. Acknowledgements

The editor acknowledges the use case contributions made by Dick Hardt, Robert Yates, Lisa Dusseault and Laurie Rae.

TOC

8. Security Considerations

None.

TOC

9. References

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[dmd1]	Merrells, J., “draft-merrells-dix-01.txt,” March 2006.
[identitygang]	The Identity Gang, “http://identitygang.org/Lexicon,” March 2006.

TOC

Author's Address

	John Merrells
	Sxip Identity
	798 Beatty Street
	Vancouver, BC V6B 2M1
	Canada
Email:	merrells@sxip.com
URI:	http://sxip.com/

TOC

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.

--Apple-Mail-11--476896285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-11--476896285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name="draft-merrells-use-cases-02.txt" Content-Disposition: attachment; filename=draft-merrells-use-cases-02.txt Network Working Group J. Merrells Internet-Draft Sxip Identity Expires: September 2, 2006 March 2006 Digital Identity Exchange - Use Cases draft-merrells-use-cases-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the motivating use cases for DIX, the Digital Identity Exchange protocol. Merrells Expires September 2, 2006 [Page 1] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Browser Based Use Cases . . . . . . . . . . . . . . . . . . . 8 5.1. B1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. B2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. B4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. B5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. B6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.7. B7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. B8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.9. B9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.10. B10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.11. B11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.12. B12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.13. B13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.14. B14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.15. B15 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.16. B16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.17. B17 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.18. B18 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.19. B19 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.20. B20 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.21. B21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.22. B22 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.23. B23 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.24. B24 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.25. B25 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.26. B26 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.27. B27 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.28. B28 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.29. B29 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.30. B30 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.31. B31 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.32. B32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.33. B33 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.34. B34 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Non Browser Based Use Cases . . . . . . . . . . . . . . . . . 15 6.1. NB1 - REST . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. NB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. NB3 - WebDAV . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. NB4 - AtomPub . . . . . . . . . . . . . . . . . . . . . . 15 6.5. NB5 - XCAP and SIMPLE . . . . . . . . . . . . . . . . . . 15 6.6. NB6 - CalDAV . . . . . . . . . . . . . . . . . . . . . . . 16 Merrells Expires September 2, 2006 [Page 2] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 6.7. NB7 - IMAP/POP3 and CalDAV . . . . . . . . . . . . . . . . 16 6.8. NB8 - RSS, Web, and CalDAV . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Merrells Expires September 2, 2006 [Page 3] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Merrells Expires September 2, 2006 [Page 4] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 2. Introduction The use cases below describe various scenarios for the Digital Identity Exchnage (DIX) protocol [dmd1]. Merrells Expires September 2, 2006 [Page 5] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 3. Goals The goals of the protocol are: Identity Information Exchange: The primary goal of any DIX protocol is to automate the exchange of Identity Information over the Internet. Ease of Adoption: Any DIX protocol must provide the lowest possible barriers to adoption to ensure wide-spread usage of the protocol. Internet Scale: Any DIX protocol must provide an Internet scale solution to identity information exchange. Privacy: Any DIX protocol must ensure that all aspects of user privacy can be maintained. Merrells Expires September 2, 2006 [Page 6] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 4. Definitions The following terms and their definitions are drawn from the lexicon of 'The Identity gang', a community of thought leaders in the user- centric digital identity space. [identitygang]. Digital Identity - The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more other Parties. Identity Agent - An agent acting on behalf of the user. Identifier - An identifying attribute for a set of attributes. Identity Data / Identity Information - A set of attributes. Claim - An assertion made by a Claimant of the value or values of one or more attributes of a Digital Subject, typically an assertion which is disputed or in doubt. Merrells Expires September 2, 2006 [Page 7] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 5. Browser Based Use Cases Some use cases are dependent upon others, so should be perused in order. Beth is our protagonist throughout; a typical Internet user, but she's a bit of a geek. 5.1. B1 Beth receives an email from a friend introducing her to a new website, geeknews.com, a techie news site. She wishes to sign up so that she can read some articles. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geeknews.com is requesting some data, her first name. She enters 'Beth' at the prompt, provides consent and the data is sent to the site. 5.2. B2 Beth browses to geekdate.com, she clicks an IN button. Her identity agent informs her that geekdate.com is requesting some data, her first name. Her agent already has this data. She provides consent and the data is sent to the site. 5.3. B3 Beth decides to create a profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an identifier. She provides consent and the identifier and identifier verification data is sent to the site. Geekdate.com uses the verification data to verify that Beth owns the identifier her agent provided. 5.4. B4 Beth decides to create a new profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an Identifier. She instructs her identity agent to create an identifier specific to her relationship with geekdate.com. She provides consent and the data is sent to the site. 5.5. B5 Beth decides to flesh out her profile at geekdate.com. Geekdate.com displays a registration form. One field requests a URL of a photo of her. Beside it is a SAVE button. She enters the URL and clicks the button. Her identity agent displays a screen informing her that this Merrells Expires September 2, 2006 [Page 8] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 data item can be stored. She decides that she wants to be able to provide that data to other sites. She provides consent and the data is stored by her agent. 5.6. B6 Geeknews.com offers Beth the option to build up a readership preferences profile over time, the benefit being that the site will tailor its content to her interests. She decides to take up the offer, she sees an IN button, which she clicks. Her identity agent informs her that geeknews.com is requesting some data, an Identifier. She selects an existing identifier that represents a subset of her identity, which is used for a subset of the sites she has a relationship with. She provides consent and the data is sent to the site. 5.7. B7 Beth wants to have multiple identifiers, for different aspects of herself, her personas. She wants to have a 'home' persona for identity data that she releases to her personal sites, such as geeknews.com. She wants to have a separate 'work' persona for identity data that she releases to work-related sites, such as helpdesk.com. She wants some of her identity data to be the same for her different personas, and other data to be different. 5.8. B8 [Assumptions: Beth has visited geeknews and geekdate before and has informed her identity agent that she consents to a relationship with them.] Beth starts her day with a strong coffee and a perusal of geeknews.com. She starts her computer and authenticates herself to the operating system. By that authentication mechanism she has also authenticated herself to her identity agent, as her vendor of that system has hooked it into the operating system's authentication system. She browses to geeknews.com and clicks the IN button and is directly shown the content, no further clicks. She then browses to geekdate.com, she clicks the IN button and is directly presented with her profile no further clicks. 5.9. B9 Beth's identity agent prompts her to provide a 'spoken name'. Using the multimedia capabilities of her computer she records her spoken name; an mp3 of her saying 'Beth'. She later browses to voicebox.com, which runs a voicemail service, she opts to create an account and the site requests some properties, amongst which is a request for her spoken name. She provides consent and the data is Merrells Expires September 2, 2006 [Page 9] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 sent to the site. 5.10. B10 Beth purchases a book from an online store, as she's checking out the store makes her an offer: 10% off for completion of a demographic survey. She's tempted, but how many data fields are there? One hundred! Too many to be worth the effort. But it happens to be commonly requested data, which she has already entered during previous exchanges with other sites. So, she completes the remaining fields, saving them to her identity agent for future reuse. She provides consent and the data is sent to the site. 5.11. B11 Beth has invested significant effort in building up a persona and reputation around a specific identifier, her 'home' identifier. But, she has become dissatisfied with her identity agent and so decides to switch vendors. She establishes a new agent and migrates her identity data from the old one to the new one. She then delegates authority for her identifier to her new identity agent for authentication and provision of identity data. 5.12. B12 Whilst in town Beth stops off at an Internet Cafe to check her email. She goes to her webmail account, which requires that she identity herself. Her Identity Agent prompts her for consent and provides her identifier so that she can gain access to her email. 5.13. B13 Beth visits a website to purchase some books. The site requests some identity information, her shipping address. Her Identity Agent warns her that satisfying the request would contravene her established privacy policy. The website wishes to pass her address to affiliated companies so that they may send her valuable promotional offers, but Beth has a privacy policy that not allow unsolicited mail to be sent to her shipping address. 5.14. B14 Beth moves house, so she changes the home address information stored by her Identity Agent. Her Identity Agent offers to notify all relying parties to whom she has previously provided her home address. Merrells Expires September 2, 2006 [Page 10] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 5.15. B15 Beth is a frequent traveler on Galactic Air, whose site offers a claim of membership for use at affiliate sites. She acquires a membership claim, which her Identity Agent stores for her. 5.16. B16 Beth visits a Galactic Air affiliate site that provides discounted travel insurance for frequent travelers. She presents her Galactic Air membership claim from her Identity Agent and receives a discount. 5.17. B17 Beth visits a rental cars site. She opts out of the offered drivers insurance as she is covered by her travel insurance. To complete the booking the site requests a claim that she has valid insurance. Her identity agent is unable to satisfy the request so provides a list of suggested sources. Beth picks her insurance provider and her identity agent acquires the required claim and presents it to the rental car site. 5.18. B18 A couple of months later Beth books another trip. The travel site requests her claim of Galactic Air membership. Her identity agent finds that the claim has expired, so refreshes it by requesting an updated claim from galacticair.com. 5.19. B19 Beth leaves work and goes to the bus stop. Whilst waiting for the next bus home she uses her smart phone to browse geeknews.com. Her Identity Agent provides her with the same ease of browsing that she experiences on her work and home computers. 5.20. B20 Beth is ending her day at work. She leaves work and waits for the next bus home. Her friend calls and invites her to the movies. She uses her phone to browse to the movies.com to find out what's playing. The site requests her current location, which she consents to release via her Identity Agent. 5.21. B21 Beth signs up with a financial services site, BigPicture.com, which provides an aggregate view of her finances. To provide its service Merrells Expires September 2, 2006 [Page 11] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 BigPicture.com requires access to her existing bank accounts. Beth wishes to securely provide agency rights to BigPicture.com, so she acquires the appropriate access tokens from her existing bank account providers and stores them with her Identity Agent. She then presents the access tokens to BigPicture.com so that it can access her account data. 5.22. B22 Beth goes to an auction side, ibay.com. Her Identity Agent shows a signed graphic of ibay.com for releasing data. Beth knows that she's dealing with ibay.com, and not an impostor. 5.23. B23 Beth visits her online bank, which requires the use of a strong authentication mechanism. She authenticates to her Identity Agent using a two-factor device indicated by the bank to be an acceptable mechanism. 5.24. B24 Adam uses a service to acquire a verified email claim. With it he can prove that he owns his email address, Adam@example.com, without having to go through a verification process. 5.25. B25 Beth gives her friend, Adam@example.com, access to her photos. Adam receives an email from Beth inviting him to view her photos. He goes to the site, which requests a verified email claim. He presents his claim and gains access to the photos Beth has published for him. 5.26. B26 Adam decides to create a profile at geekdate.com. geekdate.com requests an Identifier. He instructs his identity agent to create an identifier specific to his relationship with geekdate.com. 5.27. B27 Adam visits a site that requires that he prove he is over 21. He provides the site with a claim that he is over 21, issues by the government of his country of residence, gov.ca. The claim contains no other information about Adam and the site is unable to use the claim to discover more information about Adam. Merrells Expires September 2, 2006 [Page 12] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 5.28. B28 Adam returns to the same site. He must again prove that he is over 21. He provides a claim, but the site cannot tell that it is Adam that has returned again to the site. 5.29. B29 Adam heavily frequents two gambling sites, goldenslots.com and luckydice.com. He uses the same identifier across both sites as he wants them to know he is the same person. 5.30. B30 Beth provides a claim from galacticair.com to many different websites. She wants all of the sites to know that she is the same person providing the claim, so she can receive a free flight at the end of the year. 5.31. B31 Beth's employer has partnered with a local university to provide it's staff with access to online courses. She signs up for some modules at the university admissions website acquiring an enrollment claim. She then browses to the computer science school website to sign up for an advanced programming course. The site requests claims that she is an employee, that she has previously completed some basic introductory modules, and that she has been enrolled. 5.32. B32 Beth is shopping online for a new laptop computer. She visits an online site that caters to recently graduated professionals. She selects a machine and investigates the lease options available. To work out the monthly payment the site requests some claims: A claim that she's an alumni of a university, so that the site can include an appropriately branded tote bag. A claim that she's a member of Galactic Air, so that she can be credited with airmiles for her purchase. And, a claim from a credit scoring agency that she has a 'good' credit rating. 5.33. B33 Beth is at home checking her work email, she has an email from a colleague assigning a customer support issue to her. The company help desk system is provided by helpdesk.com, an on-demand application provider. She clicks through a link in the email to the page that describes the issue. Helpdesk.com requests a claim that Merrells Expires September 2, 2006 [Page 13] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Beth is an employee of 'Nano Software Inc', which she provides from her Identity Agent, and she gains access to the page. 5.34. B34 Beth has many computing devices in her life, running different operating systems and different application software. She makes her own choices about her own computing environment, but she has little choice when the software is bundled by the device manufacturer or at work where she is subject to her employer's policies. A consequence is that she has multiple Identity Agents, which she uses for managing different personas. Merrells Expires September 2, 2006 [Page 14] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 6. Non Browser Based Use Cases 6.1. NB1 - REST Beth wants to use QOPO.com for printing her pictures that are stored in flackr. She visits QOPO.com and her identity agent is instructed to acquire a token from flackr. Her Identity Agent retrieves the token from flackr and presents it to QOPO.com. QOPO.com passes the token over the REST based web service that flackr provides to retrieve her photos for printing. 6.2. NB2 Beth is a big fan of Rocky Gervas and listens to his podcast fanatically. The Rocky Gervas show recently started charging a small fee for the podcast. Her media player polls the podcast periodically. When polled the site requests a claim from Beth's Identity Agent asserting that Beth has paid for the podcast. Beth's Identity Agent retrieves the claim presents it to the site and the latest episode of The Rocky Gervas show is downloaded. 6.3. NB3 - WebDAV At work Beth uses her website editing software (a WebDAV client) to publish some company confidential content to their extranet. Beth is collaborating with Charles at another company, who requires access to the content. Beth configures the extranet to allow Charles access. Charles uses his website editing software (also a WebDAV client) to fetch the content. The extranet site requests identity information, which his client presents from his Identity agent, and he is able to edit the content. 6.4. NB4 - AtomPub Beth uses a blogging client (AtomPub) to both post content to her blog and to add comments on other people's blog postings. Her client uses her identity agent to associate identifying information (her blog url and favicon) with her comments. 6.5. NB5 - XCAP and SIMPLE Beth uses her instant messaging client (a SIMPLE client) to communicate with her friends. She uses her client to update her profile information (via XCAP), adding a new friend. Her client didn't need to authenticate to her XCAP server, as she had already authenticated herself to her identity agent. Merrells Expires September 2, 2006 [Page 15] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 6.6. NB6 - CalDAV Beth needs to arrange a conference call with Charles. She uses her calendaring software (a CalDAV client) to publish her free-busy time to Charles. Charles uses his calendaring software (also a CalDAV client) to fetch Beth's free-busy time. Beth's calendar publisher requests some identity information of Charle's client. It's provided from his identity agent and he is able to book a time for the call. 6.7. NB7 - IMAP/POP3 and CalDAV At work Beth uses both calendaring (CalDAV) and email (IMAP,POP3,SMTP) clients to manage her time and messages. Her identity agent authenticates her as owning the identifier that both clients use to identify her. In this way she need only authenticate once to her identity agent instead of twice, once to each client. 6.8. NB8 - RSS, Web, and CalDAV Beth works in a distributed workgroup collaborating with colleagues, individual contractors, and employees of partner companies. The calendaring information she has access to is available via CalDAV, RSS, and HTTP/HTML. Each of her software clients uses her identity agent to ensure she need only authenticate once, instead of once per client. Merrells Expires September 2, 2006 [Page 16] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 7. Acknowledgements The editor acknowledges the use case contributions made by Dick Hardt, Robert Yates, Lisa Dusseault and Laurie Rae. Merrells Expires September 2, 2006 [Page 17] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 8. Security Considerations None. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [dmd1] Merrells, J., "draft-merrells-dix-01.txt", March 2006. [identitygang] The Identity Gang, "http://identitygang.org/Lexicon", March 2006. Merrells Expires September 2, 2006 [Page 18] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Author's Address John Merrells Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 Canada Email: merrells@sxip.com URI: http://sxip.com/ Merrells Expires September 2, 2006 [Page 19] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Merrells Expires September 2, 2006 [Page 20] =0C --Apple-Mail-11--476896285 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-11--476896285-- From dix-bounces@ietf.org Tue Apr 18 08:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp47-0004sW-2I; Tue, 18 Apr 2006 08:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp46-0004sR-Mo for dix@ietf.org; Tue, 18 Apr 2006 08:12:18 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp45-0002kK-5l for dix@ietf.org; Tue, 18 Apr 2006 08:12:18 -0400 Received: by nz-out-0102.google.com with SMTP id 18so1213849nzp for ; Tue, 18 Apr 2006 05:12:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UXwXJKRsB7ujD9e0RO/Nz12u1cO7R3iqWGECvafVqbu7RXdwg5yqUxbbQ9+yrGN0fOjpTAkelAG2qOkCXhjzIawnvXT+fAvOEs0MeSuc18xNKsplWbTKC2JiO0wqnl/yZSU9Dmc3XiN6UiZXltTtGdMyNB/YkzQ9kYpFraWPfgo= Received: by 10.65.52.4 with SMTP id e4mr1102708qbk; Tue, 18 Apr 2006 05:12:16 -0700 (PDT) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id e17sm1349002qbe.2006.04.18.05.12.15; Tue, 18 Apr 2006 05:12:16 -0700 (PDT) Message-ID: <4444D79D.1020708@gmail.com> Date: Tue, 18 Apr 2006 08:12:13 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft-merrells-use-cases-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org John Merrells wrote: > > Here's an update to the use cases draft that incorporates the > comments on the list over the past week. > > John > John, these are great, I have a question on scope of the use cases though. I notice that in the non browser use cases there are some non http use cases e.g. SIMPLE, IMAP. I was under the impression, probably from dmd0, that we were just looking at having a binding of DIX into http initially, so...... Is it the intention of the use cases to cover all protocols or just http? If it is all protocols then I think the non-browser use cases need considerable expansion. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Apr 18 15:59:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwMB-0007yu-Nx; Tue, 18 Apr 2006 15:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwMA-0007yp-Ug for dix@ietf.org; Tue, 18 Apr 2006 15:59:26 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwM9-00032y-J6 for dix@ietf.org; Tue, 18 Apr 2006 15:59:26 -0400 Received: from [192.168.1.66] (adsl-69-106-251-0.dsl.pltn13.pacbell.net [69.106.251.0]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k3IJxN0T028719 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 18 Apr 2006 12:59:24 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <4444D79D.1020708@gmail.com> References: <4444D79D.1020708@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-use-cases-02 Date: Tue, 18 Apr 2006 12:59:22 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.749.3) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 18-Apr-06, at 5:12 AM, Robert Yates wrote: > I notice that in the non browser use cases there are some non http > use cases e.g. SIMPLE, IMAP. I was under the impression, probably > from dmd0, that we were just looking at having a binding of DIX > into http initially, so...... Is it the intention of the use cases > to cover all protocols or just http? If it is all protocols then I > think the non-browser use cases need considerable expansion. The charter as currently drafted roughly says 'http binding now, other bindings later, if people want them.' So, I collated the use cases from the list with that remit. I think that the browser use cases are complete enough that other documents could be written against them. But the non-browser cases clearly aren't detailed enough for that. dmd0/dmd1 attempts to address just the browser cases. dmuc2 can be developed further if people want to do that and should be taken further if people want to write further documents against them. What do you folks on the list want to do with dmuc2? Does it document the goals and motivations of the group? Does it do so well enough to move forward with finding solutions that solve those problems? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Apr 19 19:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWLy1-000107-CA; Wed, 19 Apr 2006 19:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWLy0-000102-OM for dix@ietf.org; Wed, 19 Apr 2006 19:20:12 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWLxz-0006YS-Cb for dix@ietf.org; Wed, 19 Apr 2006 19:20:12 -0400 Received: from [192.168.1.66] (adsl-69-106-251-0.dsl.pltn13.pacbell.net [69.106.251.0]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k3JNK2em085312 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Apr 2006 16:20:03 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <6D05DA72-1105-4D35-95D3-7F015994A012@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Wed, 19 Apr 2006 16:20:01 -0700 X-Mailer: Apple Mail (2.749.3) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [dix] IIW & DIX X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org An 'Internet Identity Workshop' is being held in Mountain View, CA, May 1-3. Details here: http://iiw.windley.com/wiki/Main_Page IIW is a forum for discussion of identity issues and a good opportunity to meet some great people who are thinking about, writing about, and building user centric identity systems. Are you attending? Will you be in the vicinity at the time? I think it'd be great to have a DIX group meeting to talk about moving DIX forward. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Apr 27 16:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZD8X-0005lt-Sp; Thu, 27 Apr 2006 16:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZD8W-0005lj-O9 for dix@ietf.org; Thu, 27 Apr 2006 16:30:52 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZD8V-00010I-FC for dix@ietf.org; Thu, 27 Apr 2006 16:30:52 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1221C14229B for ; Thu, 27 Apr 2006 13:30:51 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25269-10 for ; Thu, 27 Apr 2006 13:30:50 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B0734142292 for ; Thu, 27 Apr 2006 13:30:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> References: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C2CB823-042C-46C3-BB92-3CF7DEDC5AAF@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: SAML and REST - was Re: [dix] DIX use cases Date: Thu, 27 Apr 2006 13:30:38 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mar 23, 2006, at 11:50 AM, thayes0993@aol.com wrote: > No! I think the intended scope of DIX is to work within the > existing HTTP capabilities. In fact, DIX is intended to work in an > HTML/browser environment, rather than in non-HTML applications such > as WEBDAV or even browser-based AJAX schemes. > > I'd like to discuss changes to HTTP somewhere, but probably not on > the DIX list. > There is a list specifically to discuss HTTP Authentication: I had hoped that this list would at least identify a problem statement around what needs to be fixed, if anything, in HTTP authentication. Possible problem statements might involve fixing the signature algorithms or allowing 3rd-party identity statements. Lisa > Terry > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Apr 28 16:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZV6-0000Ik-AX; Fri, 28 Apr 2006 16:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZV4-0000FW-J2 for dix@ietf.org; Fri, 28 Apr 2006 16:23:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZV4-0001Yx-HX for dix@ietf.org; Fri, 28 Apr 2006 16:23:38 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZZV2-0005yL-Ub for dix@ietf.org; Fri, 28 Apr 2006 16:23:38 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE689142271 for ; Fri, 28 Apr 2006 13:23:35 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01602-05 for ; Fri, 28 Apr 2006 13:23:35 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B64E14226F for ; Fri, 28 Apr 2006 13:23:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: Lisa Dusseault Date: Fri, 28 Apr 2006 13:23:28 -0700 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.1 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [dix] Permanent IDs and how to obsolete an identity X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Somebody was talking to me about how IDs similar to "myname@serviceprovider.com" are useless because you can't trust the ID when the service provider is gone. Isn't it the general expectation that these IDs are impermanent? Just like when my email address at work becomes obsolete when I leave the job -- I just stop using that ID. In fact it may be easier to obsolete an ID than an email address. OTOH it might not be, there might be permissions and preferences scattered about the Web, associated with an ID that suddenly becomes useless. The statement that "permanent IDs are not required" might be useful in the charter. There may also be interesting use cases about how to obsolete an ID. Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix