Subject: [dix] Requirements

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Jun 2006 11:42:27 -0700

I'm new to what people are trying to do here, so please forgive my  
ignorance.

After reading the use cases document and the protocol document, I'm  
scratching my head as to where they meet. It would be helpful if the  
requirements derived from the use cases were explicitly documented,  
so that the proposed solution could be evaluated against the  
requirements; otherwise, any number of approaches would work.

Most of the Browser-Based use cases, for example, could be met by  
modern browsers that keep identifying information on behalf of users,  
possibly along with P3P and APPEL (to manage the users' preferences  
about releasing it). The only requirements there that aren't met  
having to do with portability of identity across devices, but that  
could be met by a persistence format.

I suspect that there are a few unwritten requirements implied here,  
including;

* That an "identity agent" be a separate network entity, potentially  
under the control of a separate party, which has its own identity.
* That currently deployed user agents be able to use them without  
modification.

Is this the case, and are there more? Knowing these kinds of  
assumptions and requirements would be helpful in evaluating this  
proposal.

Also, some discussion of what motivated the choice of SAML (which  
even its strongest proponents wouldn't call "simple") would be helpful.

Cheers,

--
Mark Nottingham
[email-masked]

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

---

From: John Merrells <[email-masked]>
Date: Tue, 6 Jun 2006 16:01:23 -0700

On 6-Jun-06, at 11:42 AM, Mark Nottingham wrote:

> scratching my head as to where they meet. It would be helpful if  
> the requirements derived from the use cases were explicitly  
> documented,

I think that would be a good thing to do. We started there, but  
people wanted use cases first, so the documentation of the  
requirements got left behind. Volunteers welcome.

> requirements; otherwise, any number of approaches would work.

Yes, it'd be good to map the solution documents back onto the  
requirements.

> modern browsers that keep identifying information on behalf of  
> users, possibly along with P3P and APPEL (to manage the users'  
> preferences about releasing it). The only requirements there that  
> aren't met having to do with portability of identity across  
> devices, but that could be met by a persistence format.

Well, some cases, but not all, eg:

B3 - third party authentication
B6 - reuse of an identifier across multiple sites

And once you get into moving third party assertions around there's no  
browser that can help you there.

> I suspect that there are a few unwritten requirements implied here,  

Well, none of the requirements are actually written down. There's  
just the goals and the use-cases..

> * That an "identity agent" be a separate network entity,  
> potentially under the control of a separate party, which has its  
> own identity.

The IA can be implemented in multiple ways. As a website, or as an  
application. That requirement probably doesn't hold.

> * That currently deployed user agents be able to use them without  

Yes, that requirement would satisfy the goal of 'ease-of-adoption'.

> even its strongest proponents wouldn't call "simple") would be  

We had a simpler solution, see draft-merrells-dix-01. The audience of  
the DIX BOF felt that existing technology (ie. SAML) should be reused  
as much as possible. So, I'm trying to recast DIX as SAML where they  
overlap, and keep just the distinctive DIX pieces that meet the use- 
cases that the existing SAML profiles do not satisfy.

John