On 6-Jun-06, at 11:42 AM, Mark Nottingham wrote:
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,
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.
so that the proposed solution could be evaluated against the
requirements; otherwise, any number of approaches would work.
Yes, it'd be good to map the solution documents back onto the
requirements.
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.
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,
including;
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
modification.
Yes, that requirement would satisfy the goal of 'ease-of-adoption'.
Also, some discussion of what motivated the choice of SAML (which
even its strongest proponents wouldn't call "simple") would be
helpful.
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
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
