Subject: [dix] draft-merrells-use-cases-01

From: John Merrells <[email-masked]>
Date: Mon, 10 Apr 2006 11:16:16 -0700

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.

John

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: "Tom Doman" <[email-masked]>
Date: Tue, 11 Apr 2006 11:08:15 -0600

John,

This is good stuff John!

I have a question about use case B3.  What is the "Identifier" being requested by geekdate.com and how did Beth provide it?  She gave consent and the "data" was sent but, what data?  Maybe you're trying to be a bit vague here as in the "Identifier" in B5, B6, etc. to leave it more open but could you perhaps provide some examples of some of Beth's "Identifiers"?  I think that would clarify this for me.  I'm assuming that these "Identifiers" are becoming "personas" in later use cases, is this correct?

Thanks,
Tom

>>> John Merrells <[email-masked]> 4/10/2006 12:16:16 pm >>>

Added:

John

---

From: John Merrells <[email-masked]>
Date: Tue, 11 Apr 2006 16:41:05 -0700

On 11-Apr-06, at 10:08 AM, Tom Doman wrote:

> I have a question about use case B3.

Hmm, it's a bit brief isn't it. Maybe it needs to be beefed up.
It should probably suggest that geekdate.com verifies that
Beth does in fact own the identifier she provides.

> What is the "Identifier" being requested by geekdate.com and how  
> did Beth provide it?  She gave consent and the "data" was sent but,  
> what data?

The data is the identifier... and maybe whatever additional data is  
needed to verify that identifier.

> Maybe you're trying to be a bit vague here as in the "Identifier"  
> in B5, B6, etc. to leave it more open but could you perhaps provide  
> some examples of some of Beth's "Identifiers"?

Well there's are multiple possible solutions.
On the list, both URLs and email addresses have been suggested.
draft-merrells-dix suggests URLs, such as:

http:/www.home.com/beth

> I think that would clarify this for me.  I'm assuming that these  
> "Identifiers" are becoming "personas" in later use cases, is this  
> correct?

Yes, B7 introduces this:

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.

John

---

From: "Haripriya S" <[email-masked]>
Date: Wed, 12 Apr 2006 05:01:27 -0600

Hi,

The use cases draft made lot of things clearer to me. I went through
the document, and have a few comments. I have not followed the recent
discussions in the list since my membership had some issues, so ignore
if some of my comments are already covered in the list or obvious.

1. B6 and B7 look the same.

2.  B11: The  sentence 'Beth administers her identitier'  is not very
clear? Probably an example using email or URL as an identifier can help
here.

3. B12: (internet cafe case) Should we call out that that she first has
to authenticate with her identity agent?

4. B13: Can we have an example of a simple privacy policy here, so this
becomes clearer?

5. B14: Can the identity agent also do a similar operation if the user
wants to discontinue her relationship with a particular service (should
the agent be able to carry out the deprovisioning/deleting of the user
information stored at the service site)?

6. B16: The identity agent should present the membership claim, not the
user.

7. B21: The relationship of the identity agent to the site acting as
agency for the bank account is not clear. 

8. B27: The last sentence is not very clear. Does it mean "the site can
verify Adam is over 21 but cannot get any other details of Adam
including who he is (anonymous transaction?)"?

9. B29 and B30: I understood these use-cases to mean that a user can
use either the same identifier(B29) or the same claim(B30) to different
sites to enable them to correlate that it is the same user using their
services. Is that a right understanding?

10. Can the user have more than one identity agent? Is this an allowed
scenario, for which use cases are required? Imagine a
organization-recommened identity agent, and a personal choice?

Thanks and Regards,
Haripriya S.
 
>>> John Merrells <[email-masked]> 04/10/06 11:46 PM >>> 

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.

John

---

From: John Merrells <[email-masked]>
Date: Wed, 12 Apr 2006 11:31:50 -0700

> 1. B6 and B7 look the same.

Actually B5 and B6 are identical - oops.

B6 says Beth can share an identifier across multiple sites.

B7 says Beth can have multiple identifiers.

Should I make that clearer?

> clear? Probably an example using email or URL as an identifier can  

Agreed. I don't want to presuppose the identifier design decision
though, which is why I used the vague term 'administer'. I can't
think of a way around that... 'she does something that makes her
identifier managed by another identity agent'

> to authenticate with her identity agent?

In all these cases her identity agent should authenticate her to
ensure she is Beth. I think what you're pointing out is how the
webmail service knows that she is who she says she is? This
is also an issue with B3, which I've added some text to fix. B12
could say....

Her identity agent displays a screen informing her that webmail.com  
is requesting some data, an identifier.
She provides consent and the identifier and identifier verification  
data is sent to the site.
webmail.com uses the verification data to verify that Beth owns the  
identifier her agent provided.

> 4. B13: Can we have an example of a simple privacy policy here, so  

Good idea.

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 affilliated 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.

> information stored at the service site)?

Hmm. Interesting thought. I suspect that most Membersites would
not be interested in implementing deprovisioning/deletion... I guess
the identity agent could send a bunch of null values to the MS. I
need to think about that more.

> 6. B16: The identity agent should present the membership claim, not  

Thanks.

> agency for the bank account is not clear.

Rewritten.

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.

Better?

> including who he is (anonymous transaction?)"?

Yes. Rewritten:

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.

Clearer?

> services. Is that a right understanding?

Yes.

> organization-recommened identity agent, and a personal choice?

Yes and yes. I should add a use case that makes that clear.

Thanks for your close reading of the text and your very useful comments.

John

---

From: John Merrells <[email-masked]>
Date: Wed, 12 Apr 2006 11:42:37 -0700

On 12-Apr-06, at 11:31 AM, John Merrells wrote:

> Yes and yes. I should add a use case that makes that clear.\

Added:

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.

John

---

From: Pete Rowley <[email-masked]>
Date: Wed, 12 Apr 2006 11:52:04 -0700

> identifier managed by another identity agent'

She then *delegates* authority for her identifier to her new identity 
agent so that it is authoritative for authentication and provision of 
identity data.

-- 
Pete

---

From: John Merrells <[email-masked]>
Date: Wed, 12 Apr 2006 11:53:32 -0700

On 12-Apr-06, at 11:52 AM, Pete Rowley wrote:

> She then *delegates* authority for her identifier to her new  
> identity agent so that it is authoritative for authentication and  
> provision of identity data.

Yeah! Nice.

John

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 12 Apr 2006 21:00:32 +0200

2006/4/12, John Merrells <[email-masked]>:
> >> 10. Can the user have more than one identity agent? Is this an
> >> allowed scenario, for which use cases are required? Imagine a

I first thought that the Identity Agent were a web-based service, not
some piece of software you would have to install on your "computing
device".
This is:
 - what's done today by other distributed identity systems (OpenID,
LID, Passport, etc.)
 - what's suggested by draft-merrells-dix-00 and -01

How about the "cyber café" use case? How does Beth acceed her
identities and personnas if the Identity Agent is a "local" piece of
software and not a web-based service?

I also think the protocol must have a "dumb, web-based" profile à la
OpenID or LID, using HTTP redirects combined with basic HTTP-Auth ; a
profile for using web-based services from a "bare" computer (e.g. in a
cyber café, where you cannot install anything, or a mobile device with
limited capabilities and extensibility –e.g. a mobile phone–). I think
SAML also has such a profile.

This is IMO a requirement for a distributed identity system.

--
Thomas Broyer

---

From: John Merrells <[email-masked]>
Date: Wed, 12 Apr 2006 12:17:17 -0700

> some piece of software you would have to install on your "computing

 From Beth's perspective the agent software could be either local or
remote.

I think my use case went too far in making it sound like local software.

>  - what's done today by other distributed identity systems (OpenID,

Indeed.

You could argue that Infocard solves many of these usecases with
local software.

>  - what's suggested by draft-merrells-dix-00 and -01

Correct. dmd1 is focused on the existing browser case. Building on
dmd1 you could devise smarter clients that provided Beth with a
better experience.

> software and not a web-based service?

We're getting into implementation here, but yes it could be a remote
service, or it could be in something that Beth carries around with her.

> This is IMO a requirement for a distributed identity system.

I think we're all in agreement.

Clearer? Less device oriented...

<section title="B34"><t>
Beth has many computing environments 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 within a device or when  
she's at work, where she is subject to her employer's policies.
A consequence is that she uses multiple Identity Agents, which she  
uses for managing different personas.
</t>

The first two sentences are just motivation... the last line is the  
important statement.

John

---

From: Jaimon Jose <[email-masked]>
Date: Thu, 13 Apr 2006 10:27:16 +0530

John,
John Merrells wrote the following on 04/10/2006 11:46 PM:
> 1) More browser based use cases. In particular many examples of 'claims'.
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

---

From: John Merrells <[email-masked]>
Date: Thu, 13 Apr 2006 10:20:33 -0700

Thanks for your comments.

> 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.

> For eg.  how does she inform the agent if she switches the insurance

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.

> 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.

> site doesn't store a cookie when Adam visited first time.. ( I may be

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