Subject: [dix] problem / goals / benefits / requirements / use cases

From: John Merrells <[email-masked]>
Date: Tue, 14 Mar 2006 21:27:18 -0800

OK, I just had a long plane ride, so I dumped all my thoughts about  
the above into a single message.
The problem statement is actually from the most recent draft of the  
proposed charter.
Everything else came from reading through all the DIX messages and  
from my head.
I hope that it represents our collective thoughts... but I'm sure it  
doesn't and so I'm sure you'll be letting me know. :)

John

----

Problem Statement

The Internet is host to many online information sources and services.  
There is a growing demand for users to identify, and provide  
information about themselves. Users bear the burden of managing their  
own authentication materials and repeatedly providing their identity  
information. Signing in to web pages and completing user registration  
forms is an example.

Goals
Benefit Internet Users
Protocol adoption

Benefits

Benefits to the End User
Browsing Efficiency – Reuse of Identity Data and authentication
Browsing Efficiency – Consistency of User Experience for providing data
Reuse of Identity Data – Less data entry
Reuse of Authentication – Single Sign-On
Reuse of an Identifier – Persona and reputation building
Security – Consistent user experience
Security – Stronger authentication more viable
Privacy – Choice over what is stored where and released to whom
Privacy – Choice over the degree of relationship with a site:  
anonymous, pseudo-anonymous, or public. [todo: see terms in Ben’s  
referenced document.]
Reuse of Verification Processes – By moving third-party claims  
between authority and site

Benefits to the Website Operator
Data quality, quantity, and richness.
Lower latency in workflows for verifying self asserted data.
Higher conversion rates

Requirements

Requirements for Benefits Goal
Presentation of identity data from user to site
Storage of identity data from site to user
Identifier scheme enables individual to aggregate data
Identifier scheme enables individual to create one-to-one relationships
Authentication that the user owns an identifier
Separation of identifier from information storage
User choice of what information is released to whom
No predetermined relationship between the site and the Identity Agent
No need to provide identifier with the identity data.
No need for the site to store the identity data between sessions
Separation of authentication from resource

Requirements for Adoption Goal
Meets the ‘Seven Laws of an Identity Architecture’
Zero code on the browser at a minimum
Minimal Website code
Works with existing Website code
Secure
Extensibility
Reuses existing technology

Definitions

Beth – Our protagonist and a typical Internet user, but she’s a bit  
of a geek.

Identity - Ben quotes from ‘Anonymity, Unlinkability,  
Unobservability, Pseudonymity, and Identity Management - A  
Consolidated Proposal for Terminology’:  “An identity is any subset  
of attributes of an individual which identifies this individual  
within any set of individuals. So usually there is no such thing as  
"the identity", but several of them.” http://dud.inf.tu-dresden.de/ 
Anon_Terminology.shtml

Digital Identity – Kim’s definition from ‘The Identity Gang’. “The  
digital representation of a set of Claims made by one Party about  
itself or another Digital Subject.”

Digital Identity – Bob’s rewrite of the above. “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.”

Identifier – an identifying attribute for a set of attributes.

Identity Data – a set of attributes

Identity Agent – An agent acting on behalf of Beth.

Use Cases

The use cases describe various scenarios to illustrate the benefits  
of solving this problem. Some use cases are dependant upon others, so  
should be perused in order.

1) Beth receives an email from a friend introducing her to a new  
website, geeknews.com, a site that publishes techie news articles.  
She browses the site and decides to read some articles. She sees an  
IN button, which she clicks. [Insert step 1.1, called out as it’s  
reused in many use cases.] 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. [Benefits: Choice of what is stored where and  
released to whom. Benefits: Consistent User Experience – She sees her  
agent’s user interface every time she is asked for information.]

1.1) Her identity agent performs an authentication process to ensure  
that it is representing Beth, and not an imposter. The authentication  
mechanism used is implementation dependent. The identity agent may  
provide the benefit of caching the authentication for the duration of  
Beth’s internet browsing session. [Benefit: Reuse of authentication,  
when coupled with other aspects provides single sign-on.]

2) Beth browses to geekdate.com, she clicks an IN button. [1.1] Her  
identity agent displays a screen informing her that geekdate.com is  
requesting some data, her first name. From [1] her agent already has  
this data. She provides consent and the data is sent to the site.  
[Benefit: Less data entry. Benefit: Reuse of identity data. Benefit:  
Quality data.]

3) Beth decides to create a 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 UTL and clicks the  
button. [1.1] Her identity agent displays a screen informing her that  
this data item can be stored. She provides consent and the data is  
stored by her agent. [Benefit: Reuse of Identity Data. Benefits:  
Enabled stateless sites that request the data they need for each  
session. Benefit: Persona building. Benefit: Choice of what is stored  
where.]

4) Geeknews.com offers Beth the option to build up a readership  
preferences profile overtime, 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. [1.1] Her identity  
agent displays a screen informing her that geeknews.com is requesting  
some data, an Identifier. See takes options 4.1 or 4.2. She provides  
consent and the data is sent to the site.  [Benefit: Reuse of  
authentication - Beth doesn’t have to remember account details, such  
as username and password, for the site. Benefit: Reputation building.]

4.1) Her identity agent creates an identifier specific to her  
relationship with geeknews.com. [Benefit: Privacy – Choice over  
degree of relationship. Uni-directional identity guards against the  
site correlating the data it aggregates about the identifier with  
other parties beyond this relationship. ]

4.2) 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. [Requirement: Multiple Identifiers for a person.  
Benefit: Privacy – Choice over degree of relationship.  
Compartmentalization of identity. Easier management of identity data.  
Benefit: Persona building.]

5) [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. [Benefits: Separation of  
authentication from resource and reuse of authentication provides  
single sign-on across multiple sites.]

6) 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 Beth 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. [Benefits: Richer Data.]

7) Beth purchases a book from an online store, as she’s checking out  
the store makes her an offer: 10% 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’s commonly requested  
data and she has already submitted most of the data during previous  
exchanges with other sites. She completes the remaining fields,  
saving them to her identity agent for future reuse. [Benefit Reuse of  
data. Benefit: More data for the site.]

8) 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 the new agent and migrates her  
identity data from the old one to the new one. She then administers  
her identifier so that her new identity agent is authoritative for  
authentication and provision of identity data. [Benefit: Choice of  
Identity Agent - Separation of identifier from information storage.]

Benefits in Detail

For the End User

The browsing experience is more seamless for the end user as their  
identity data at their identity agent can be reused for automatic  
form completion, and the consistent user experience of data entry  
makes data entry more familiar.

By reusing an identifier across multiple relationships the user can  
build up a reputation around that identifier, which could be parlayed  
into preferential treatment and privileged access.

An identity agent can provide for authentication reuse across  
multiple identifiers and multiple sites, providing the end user with  
a single sign-on experience.

Security against identity data theft can be provided to the user  
through a consistent user experience, as the user is less likely to  
be fooled by a fake site, as is commonly used in phishing attacks.

Security can also be enhanced by identity agents that provide  
stronger forms of authentication mechanisms, such as two-factor  
devices. This solution makes these more expensive mechanisms more  
viable as the cost is amortized across all the sites that consume  
authentication claims from the agent.

Individual privacy is enhanced in a number of ways. The user has  
choice over the degree of relationship they have with a site:  
anonymous, pseudo-anonymous, or public. The user also has choice over  
what data is stored where and released to whom. The automated  
presentation of data means that a site need no longer store identity  
data between sessions, thus reducing the risk of a security breach at  
the site revealing identity data. [todo – this is probably an essay  
better written by Ben.]

By supporting the movement of third-party claims between authority  
sites and a relying party verification processes can be reused. For  
example, a site could request a claim of verified email, rather than  
verify the email address themselves, thus introducing latency into  
the workflow by having to wait or some out-of-band process to complete.

For the Website Operator

When website operators request a user complete a form they introduce  
a barrier to the user continuing that interaction. By automating data  
release and reusing identity data a site can ask for common data  
items without introducing a barrier, thus increasing the quantity of  
data acquired and improving conversion ratios.

Because the user can reuse their identity data across many sites they  
are more likely to maintain correct data, thus improving the quality  
of the data collected.

By not storing identity data between sessions a site can mitigate its  
risk of losing sensitive identity data and can ensure that the data  
it is operating with is up to date, rather than stale.

Since data provision is automated identity data items that would not  
or could not normally be asked of a user can be requested. For  
example, long URLs, an image, or an audio clip.

By supporting the movement of third-party claims between authority  
sites and a relying party verification processes can be reused.

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 00:37:42 -0600

Cautions:

      Lest anyone find themselves wondering, what follows is intended to move
towards explicit and precise language that we can all agree on.

      To do that, I had to question quite a bit of your text.

      The good news is that your text raised a lot of questions that I think are
basic and resolving them is likely to be extremely useful.

      Your extended example are quite good at making the usage of DIX
concrete.  (A minor question is how much group consensus there is that these
examples represent the range of DIX usage; I suspect the issue is not whether
the examples are "wrong" but whether they define the scope of DIX usage
sufficiently.)

      I think the more terse language in the lists, at the beginning of your
message, perhaps assume too much a priori understanding/context.  Therefore,
much of what I  ask, in the following, is really intended to find language for
these lists that will have more common, immediate and precise meaning to a wide
range of readers.

(By the way, the cost of your sending such a lengthy and thoughtful note is a
lengthy response.  Whether it, too, is thoughtful, well... it tries to be.)

> There is a growing demand for users to identify, and provide information 
> about themselves. 

So, the focus of the DIX effort is about identification of users, as then being
able to (automatically) provide a range of attributes associated with those users?

(I believe others on the list see the scope as much more broad.)

> Users bear the burden of managing their own
> authentication materials and repeatedly providing their identity 

The examples are useful.  However I clarifying what is meant by "authentication 
materials".

Although I have my own guesses about what that term refers to, I suspect each of
us differs quite a bit in our guesses.  And for a working group charter, such
guessing -- ie, non-overlap of basic terms of reference -- is highly problematic.

> Protocol adoption

Unfortunately, the two goals you cite apply to all the work ever done for IETF 
standards.  Hence the goals say nothing that is specific to this effort.

That leaves us with an empty list of (distinctive) Goals.

> Benefits
...
> Browsing Efficiency – Reuse of Identity Data and authentication

Browsing?  So the focus of this group is strictly for web-based activity?

No
benefits for email, instant messaging, VOIP, etc?

> Browsing Efficiency – Consistency of User Experience for providing data

What does this mean?

> Reuse of an Identifier – Persona and reputation building

Does the group have consensus on the definition and use of "persona"?

And what does it mean to do "persona building"?

> Security – Consistent user experience

This one sounds interesting.  How does user experience consistency affect
security?  (Is there any empirical basis for this?)

> Security – Stronger authentication more viable

Really?  How?  Security people are rather demanding about justifications for 
such claims.

> Privacy – Choice over the degree of relationship with a site: anonymous,
> pseudo-anonymous, or public. [todo: see terms in Ben’s referenced
> document.]

What work is DIX planning to do that will define and ensure that either of these
happen?

> Reuse of Verification Processes – By moving third-party claims between 
> authority and site

What do you mean 'third-party claims'?  I assume that 'authority' refers to
whoever is making the claims?  And what do you mean 'site'?

> Lower latency in workflows for verifying self asserted data.

I do not understand any of these.

> Identifier – an identifying attribute for a set of attributes.

A single attribute is an identifier?  I think that does not match the earlier
definition.  Plus, it seems a bit circular.

An identifier is an identifying attribute?

I don't really know what that means.

> Identity Data – a set of attributes

Any random set, or are their constraints?  I suspect you mean some specific 
kinds of attributes.  What are they?  What attributes would NOT qualify?

For example, I suspect you mean that the attributes are associated with the 
entity being identified.

> website, geeknews.com, a site that publishes techie news articles. She 
> browses the site and decides to read some articles. She sees an IN 
> button, which she clicks. [Insert step 1.1, called out as it’s reused in 
> many use cases.] 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. 
> [Benefits: Choice of what is stored where and released to whom. 
> Benefits: Consistent User Experience – She sees her agent’s user 
> interface every time she is asked for information.]

This demonstrates how difficult it is to make the user experience "better".

If the user must enter a variety of information, where only some of that
information can be processed by DIX, then the user will experience the original
form, generated by the server, AND the client-side DIX form.

Having two different forms could be confusing and/or irritating to users, 
because it entails two different styles of forms.

But notice that I said "could be".  This is a usability question.  I am certain
the problem is a possibility, but not certain it will occur.

> [Benefit: Less data entry. Benefit: Reuse of identity data. Benefit: 

"quality"?  how the quality improved?

> stored by her agent. [Benefit: Reuse of Identity Data. Benefits: Enabled 
> stateless sites that request the data they need for each session. 
> Benefit: Persona building. Benefit: Choice of what is stored where.]

How is this "persona building"?  What does that mean?
...

Here is what I'm getting from your text:

DIX provides a standardized basis, for client-based interfaces:

1) to interact with the user and the user's environment,

2) to acquire a collection of information related to the user, based on requests 
from servers, and

3) selectively provide this data to the requesting servers, based on user 
permissions and contextual aggregations specific to the relationship between the 
user and a particular service

Are there functions i am missing or have gotten wrong?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: John Merrells <[email-masked]>
Date: Tue, 21 Mar 2006 07:37:00 -0600

> basic and resolving them is likely to be extremely useful.

Lots of really good questions Dave. Thanks!

> these lists that will have more common, immediate and precise  

Indeed. I should have perhaps defined terms up front and taken more
time to edit into a clearer form.

The good news is that my presentation materials for this morning's BOF
are more focused and much clearer, especially wrt goals and benefits.
I hope that they'll answer many of your questions.

> lengthy response.  Whether it, too, is thoughtful, well... it tries  

I'll reply more completely after the BOF.

Thanks

John

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 21 Mar 2006 08:07:29 -0600

> security?  (Is there any empirical basis for this?)

The good news is that there are certainly people working on  
developing an empirical basis for this.  At last week's W3C Workshop  
on Web Authentication, this was a major topic of discussion in the  
room and in several position papers <http://www.w3.org/2005/Security/ 
usability-ws/papers/>.  If you run into Stuart Schecter at this IETF,  
be sure to talk to him about the work MIT Lincoln Labs are doing on  
the topic.

At the risk of oversimplifying, the argument is that if users are  
very familiar with one frequently-used self-identification mechanism  
(which may be a password login), then it will be that much more  
difficult for bad actors to "phish" the user to provide credentials  
to any agent other than the real provider of that mechanism.

Lisa

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 09:09:43 -0600

> At the risk of oversimplifying, the argument is that if users are very 
> familiar with one frequently-used self-identification mechanism (which 
> may be a password login), then it will be that much more difficult for 
> bad actors to "phish" the user to provide credentials to any agent other 
> than the real provider of that mechanism.

Indeed that is a reasonable hypothesis.  My constant question, about anything
pertaining to user impact, is whether there is empirical data to support it.
Users have this nasty tendency to react in unexpected way -- or rather, to be
sensitive to issues that were not part of the model.  Therefore, innovative UI
design that predicts user behavior, without careful testing, usually fails.

At any rate, thanks for the pointer.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 09:15:26 -0600

> 2) to acquire a collection of information related to the user, based on 
> requests from servers, and
> 
> 3) selectively provide this data to the requesting servers, based on 
> user permissions and contextual aggregations specific to the 
> relationship between the user and a particular service

A few more thoughts have occurred to me:

User contact with remote services often requires that the user supply a variety 
of information.  The information might be appropriate to supply to many 
different services or it might be specific to a particular relationship between 
that user and a single service.

The DIX effort will define:

a) a common framework for representing user-specific information, based on an 
attribute/value model (identity-related attribute format)

b) an initial set of attribute definitions

c) one or more means (protocols) for requesting and exchanging user-specific 
attributes on behalf of the user.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 08:25:24 -0600

d/
-- 

Dave Crocker