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
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth osafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth
|