Hi Martin,
This is getting very close to what I believe is the main important
thing we need in the spec to facilitate privacy, true SingleSignOn,
and to help avoid confusing users by getting them to key IdP URLs.
The only tweak I would like to see is right at the start, and is
implemented using OPTIONAL (at the RP) pure client-side stuff (plain
HTML or JavaScript). The server-side tweak I'd like to see would be
this:
An ***IdP*** can *initiate* the OpenID login with the RP using
openid:Token.
How the User arrived at the RP with this token is not the concern of
the RP. (could be javascript, browser plugins, participating IdP
helper CGIs, or even the RP itself). The point is - the guts of the
authentication process remains unchanged and is backwards compatible,
but all the privacy-invasive components that live at the RP are thus
made *optional*.
Simple as that. User only needs to remember and use one ID. User
only needs to type it one time each day (or however long they elect to
stay logged on for). Datamatching and privacy invasion are
eradicated. No need to key custom IdP anonymity URLs ever. Even
facilitates double-blind anonymous logins (with inclusion of a simple
RP nonce extension). Win-win-win.
Kind Regards,
Chris Drake
=1id.com
Saturday, October 7, 2006, 2:49:17 AM, you wrote:
MA Dick Hardt wrote:
I like making all identifiers work the same way. The wording around
directed identity is somewhat confusing. Would be clearer if there
was a complete description of what happened. ie. complete the
transaction. In Directed Identity, the RP needs to do discovery on
the identifier provided to make sure the IdP is authoritative for it.
MA Perhaps I've misunderstood how directed identity works, but I figured
MA the flow would work as follows:
MA * The RP initiates Yadis discovery on http://anon.myidp.com/
MA * The IdP returns a document naming its authentication endpoint (in the
MA URI field) and a special anonymous token as openid:Token. openid:Token
MA may be the same as the public identifier from the previous step, but
MA this is not required.
MA * The RP initiates OpenID auth to the named endpoint using the openid:Token.
MA * The IdP notes that the special anonymous token has been used, but it
MA knows who the remote user is (via Cookies, for example) so it can
MA generate an identifier and remember that it belongs to that user/RP combo.
MA * IdP responds to RP with the generated public identifier (which *is*
MA publically resolvable, of course.)
MA * RP resolves the IdP-provided public identifier, where the IdP will
MA provide for Yadis discovery and specify that it is authoritative for
MA that URL.
MA * We're done.
MA The important thing is that, just as I've separated the public
MA identifier from the IdP token (or handle, if you like), this separation
MA also applies to the IdP-generated public identifier.
MA (sorry that this is a bit rough. I've not really spent the necessary
MA amount of time preparing the above and I'm in a hurry, so if there are
MA spots where I'm not clear I apologise and I'll clarify later! :) )
MA ___
MA specs mailing list
MA specs@openid.net
MA http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
