On 26-Jun-06, at 10:42 PM, Pete Resnick wrote:
I expect anyone who wants to propose a problem and/or solution to
be able to say how their proposal answers these questions:
I'm willing to answer these questions from the DIX perspective... for
both the problem as documented in draft-merrells-use-cases-xx and the
proposed solution in the protocol and assertion drafts.
I'd hope that others attending the BOF with a view to presenting
their ideas would surface them on this (these) lists, answer these
questions, and enter into any resulting conversations.
- What problem does this address that isn't addressed by a local
"keychain" or information database on the client? (For example,
possible answers include: "The problem of not having to change the
local user agent" and "The problem of portability".) What's the
downside if we don't solve those problems?
From the DIX use-cases:
We have as a goal 'ease of adoption'... from this flows a solution
architecture that mandates no changes to the User Agent, and minimal
changes to both the Relying Party and to the User's behaviour. All
complexity is pushed back to onto the Identity Agent, which could be
an IdP. The downside we believe is lower rates of adoption at a
slower pace.
Portability is covered by use-cases B12 and B15. Portability is
important to a large class of users as they have multiple devices for
accessing internet services. The downside of not addressing
portability is that it's a barrier to adoption... if a solution has
only one thing a potential user doesn't like they won't use it. Joel
Spolsky makes the point aptly in his book 'Joel on Software' where he
writes that the killer feature in Excel 4 that tipped the market in
the favour was the the ability to _write_ lotus 123 files. The last
objection to adoption has been removed.
DIX use-cases A1 through A14 document scenarios for the acquisition
and presentation of third-party attested assertions. From this flows
requirements upon the solution for a protocol between the Identity
Issuer (the authoritative source) and the Identity Agent. Maybe this
goes beyond the scope of your question... but it's our opinion that
that this is a problem and a solution would provide benefits to
internet users. The downside... a missed opportunity to enable many
useful services on the internet that exist in the real world today.
But, this could be layered on top of an existing architecture at a
later data. This was the approach we took when I published draft-
merrells-dix-00, but without 'claims' the solution proposal appears
to not offer enough value to some. By explicitly documenting the
claims use-cases we aimed to sketch out a roadmap of functionality
that could be built upon this digital-identity-exchange architecture.
- Does the mechanism use or extend currently deployed web
authentication mechanisms (client side and server side)? If not,
why not?
For User Authentication the DIX drafts explicitly state that it as
out of scope. It's not a problem that appears in the DIX use-cases.
The DIX use-cases motivate requirements for moving around the result
of an authentication event, rather than performing the authentication
process itself.
However, I'm glad that others are willing to document and address
that issue though.
For Server Authentication the DIX use-cases don't call that out as an
issue, but draft-merrells-dix-xx drafts do include some functionality
for providing the user with some assurance that they are dealing with
whom they think they are. We allow the request and response messages
to include references to signed logos.
- Is the client able to decide which identifying information goes
to the server?
By 'client' I take it to mean 'user'. This is a fundamental
requirement, as document in Kim's laws of identity. It's part of the
problem and every solution to be adoptable must meet this
requirement. DIX does.
- Does the mechanism involve 3rd parties for authentication or
identifying info? Does the 3rd party need to be trusted by the
relying party?
For authentication - No not really, as the user is self asserting
that they own an identifier and there's a verification mechanism to
check that they do. The identifier, a URL, may be hosted, but I don't
count that as a third party. The user's identity agent may be a
website, or an enhanced browser, but I don't count that as a third
party either.
For 'identifying info', which I think means third-party attested
attribute value assertions, then yes there is a third-party that is
the authoritative source of that attribute and yes the relying-party
has to trust that third-party to accept the assertion to be valid.
- Does the mechanism use a format for the information that has
widely available implementations?
'the information' is a bit ambiguous there, as in the question above
it's 'identifying information', which to me means an 'identifier'. In
DIX (dmd2) we state the identifier as being a URI and define a
PersonaURL property that describes how to use a URL as an identifier.
But I think you mean authentication and attribute assertions.
Authentication Assertions in DIX are response messages containing an
identifier property where the whole message has been signed using a
'lightweight' signing mechanism (HMAC). In dmd1 the message format
was name-value pairs, in dmd2 it is a SAML message. The SAML message
however mostly reuses the syntax of SAML and not much of the
semantics... work would have to be done there to make the SAML
message both look and behave as a SAML message in existing SAML
profiles. Jeff/Scott have kicked out a draft that takes an existing
SAML profile and extra-profiles it to use a 'lightweight' signing
mechanism. (I haven't read it - but i think that's the gist of it).
Attribute Assertions in DIX may be self-asserted or third-party-
asserted. Self-asserted are name-value pairs... where the value is a
UTF-8 string... to highly portable and you can impose any information
model you want on that, so long as you can serialize it into a
string. Third-party assertions are documented in draft-merrells-
assertion-xx and is a profile of a SAML assertion. Lots of code out
there to deal with those. But, there are many forms of claim that
could be used. The problem is moving them about, not creating or
consuming them..
- Are you using a mechanism to authenticate the information that
has widely available implementations?
See last para... basically SAML assertions for attributes.
I'll probably have more questions, but these are along these lines
of the ones you should be thinking about. Answers to these here on
the list will help me formulate agenda items.
I'd encourage you, and everyone, to ask more general questions of the
problem and solution proposers so that we can all learn as much about
each other's positions before we meet up in Montreal next month. I
hope that the BOF will be productive and that we'll leave there
having identified the problem(s) and with a plan for how we tackle them.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
