[fwd] [dix] An HTTP-based solution for digital identity (from: hartmans-ietf@mit.edu)

As a follow-up to the question that came up during today's
call.

Regards,
-- 
Thomas Roessler, W3C   <tlr@w3.org>





----- Forwarded message from Sam Hartman <hartmans-ietf@mit.edu> -----

From: Sam Hartman <hartmans-ietf@mit.edu>
To: dix@ietf.org
Date: Mon, 19 Jun 2006 13:31:21 -0400
Subject: [dix] An HTTP-based solution for digital identity
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
X-Spam-Level: 



Hi, folks.  I said I was working on a draft describing use cases and a
specific technical proposal.  I have that draft done and it
compliments my phishing requirements draft.  I expect to update the
phishing requirements draft based on several reviews I've received and
based on what confuses people about it when I have explained it to
them in person.


I was intrigued by Phil Hallam-Baker's idea to separate HTTP
authentication into two parts : one between a user and some
authentication/identity service and one between the authentication
service and the relying party.  It is important to standardize the
second protocol; while standard methods of authentication to a
identity service would be desirable extensions offered by specific
identity providers may be useful and can be supported.  Phil suggested
starting with something like http-digest.  I started doing that
mentally during the last IETF meeting.  I found that I was reinventing
a lot of the Kerberos ap-req exchange--the exchange used to
authenticate to the server.

I started thinking about reuse of deployed code and realized that it
would probably be desirable to use existing code rather than inventing
some new protocol.  New protocols are often more complicated than they
at first seem they need to be and I definitely think this would be on
exception.  So, I decided to put together a sketch of how you could
just use Kerberos to meet these needs.  I was shocked at how much of
the infrastructure necessary to do this is already available in
current web browsers.


So, I decided to write up a proposal on how to realize some of the
goals in this space using Kerberos and other related technologies.  I
also described the use cases I'm attempting to solve.  My use cases
are less ambitious than the DIX use cases; personally I think that is
a good thing.  I do believe that my proposal can be expanded to meet
all the use cases that impinge on protocol interactions.  My belief is
that this should be done gradually.


I'm sure someone out there is going to claim that Kerberos is a
horrible fit for this and that it is too complicated.  I encourage you
to specify an alternative in at least as much detail as I have done so
we can compare the complexity, functionality, reuse of technology and
ease of deployment of proposals.  While any comments are welcome,
alternative proposals or explanations of how I got use cases wrong may
make constructive discussion easier than comments of the form "this
sucks."


At some level, the DIX proposal is an alternative.  However as I think
more about this problem space, I'm coming to the conclusion that a
redirect based approach is not really in conflict with a longer-term
in-band approach.  My approach will work better for webdav, caldav and
other non-HTML-based approaches.  I think my approach may provide a
better user experience even for web pages once it is available.
However the DIX proposal can be deployed with much less effort.  If
both proposals end up using SAML to express information about
identity, they could be complimentary.


I do have some serious questions about whether a redirect-based
approach should be standardized.  I'll ask those questions in another
message.  I'm also talking to people interested in deploying
redirect-based approaches along with those who have done so, trying to
get a more informed opinion.

Any way, I'd like to draw your attention to
draft-hartman-webauth-00.txt.  Let the flames begin.

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix



----- End forwarded message -----

Received on Monday, 19 June 2006 19:06:06 UTC