EAUT as an OpenID Extension?
David Fuelling
Just wondering what your thoughts are on creating a formal OpenID 2.0
extension for EAUT. It would be a pretty small extension document,
essentially delegating all EAUT functionality to the EAUT spec.
My rationale is that OpenID 2.0 Auth doesn't really allow email
addresses as Identifiers (at the very least, it doesn't address what
to do with them). So the extension could merely address a new form of
allowed OpenID 2.0 Identifier (an email address), what to do with the
new Identifier, and possibly discuss some security issues with regard
to RP's and OP's, etc.
I still like the idea of moving EAUT into the OWF, but I think a
formal OpenID extension would be useful on several different fronts,
especially since there's so much interest in EAUT as it is in the
OpenID world.
Thoughts?
David
Will Norris
Honestly, I started replying to this email about three times saying
how I completely disagree with your recommendation, but after thinking
about it more, I'm not entirely sure. I was opposed b/c I didn't
think it was really necessary, and I was concerned about redefining
such a fundamental part of OpenID (the Identifier). I had actually
forgotten that the definition includes XRIs, which got me thinking a
bit. XRIs can work as OpenIDs, simply because there is a specified
way of performing discovery... either through native XRI resolution,
or using a proxy which converts the XRI into an HXRI. It works b/c we
have a way of converting this non-http identifier into an http
identifier. EAUT does exactly that for email addresses, so it could
in theory work the same way. For all intents and purposes, email
addresses *could* be first-class OpenID identifiers, with EAUT being
the specified discovery mechanism. (I realize I'm basically repeating
David here, but it helps me straighten it out in my head to walk
through this :) ). I'll have to think through it a little more and
make sure we wouldn't be breaking anything, but yeah... I think this
could make sense.
-will
David Fuelling
Great Thoughts!! Keep 'em coming!
I think I still haven't come to terms with making an Email address a "1st Class" OpenID Citizen -- on the one hand I like the *idea* of having a URL underneath OpenID (and it may be required at some level), but there does seem to be a lot of benefits to making an email address a 1st class openid identifier.
Probably at first, though, the extension should attempt to support emails as 2nd class citizens, since the topic has the past pattern of generating *lots* of disagreement on the OpenID lists (2nd class email addresses tends to mute the opposition a bit, and besides, I'm not even sold on the idea of them becoming 1st class). ;)
-will
Will Norris
On Aug 25, 2008, at 10:28 AM, David Fuelling wrote:
> I think I still haven't come to terms with making an Email address a
> "1st
> Class" OpenID Citizen -- on the one hand I like the *idea* of having
> a URL
> underneath OpenID (and it may be required at some level), but there
> does
> seem to be a lot of benefits to making an email address a 1st class
> openid
> identifier.
>
> Probably at first, though, the extension should attempt to support
> emails as
> 2nd class citizens, since the topic has the past pattern of generating
> *lots* of disagreement on the OpenID lists (2nd class email
> addresses tends
> to mute the opposition a bit, and besides, I'm not even sold on the
> idea of
> them becoming 1st class). ;)
Right... it's now at least possible to make emails 1st class
identifiers with EAUt. Now the question of SHOULD we do it is another
issue altogether.
-will
David Fuelling
that is "What should an RP do when EAUT Discovery fails on an email
address?". This is outside of the scope of EAUT, but very much
applicable to an OpenID transaction. For example, the OpenID
extension might just say, "Do Directed Identity on the domain", or it
might say, "Look in DNS" or whatever.
David
David Fuelling
that is "What should an RP do when EAUT Discovery fails on an email
address?". This is outside of the scope of EAUT, but very much
applicable to an OpenID transaction. For example, the OpenID
extension might just say, "Do Directed Identity on the domain", or it
might say, "Look in DNS" or whatever.
David
On Aug 25, 5:46 pm, Will Norris <w...@willnorris.com> wrote:
David Fuelling
I've been thinking about my previous post on this topic, and am
wondering if the following change to the EAUT spec would take away the
need to create an OpenID extension based on EAUT, and improve EAUT
overall.
Here's what I'm thinking: Revise section 4.1.5 of the spec to read as
follows: "The resulting URL is a valid EAUT Discovery Endpoint URL
and can be used to perform EAUT Discovery. If EAUT Discovery is again
unsuccessful on this final Endpoint URL, the Processing-Agent *may*
consult a mapping service of its choice, possibly by consulting user-
input. If no mapping service is desired, or selected by the end-user,
then the final result of the EAUT protocol is the URL 'http://
domain.tld', where 'domain' and 'tld' are take from the provided email
address."
Note here that this would remove any sort of EAUT failure mode.
For purposes of OpenID, this would be ideal, since email addresses
that have neither a specified template nor a specified mapping service
would be mapped to (at the very least) a URL that could be used for
Directed Identity (e.g., until Google supports EAUT, "be...@gmail.com"
would map to 'http://gmail.com', and beth could login with via OpenID
at Google's OP).
Additionally, this change overtly allows RP's to self-select a mapping
service for use in the event that the user has not specified one (this
is ambiguous at present). Of course, as is currently the case, a user-
specified mapping service would still take precedence over the
Processing Agent's default Mapping Service.
Thoughts?
David