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

An ***IdP*** can *initiate* the OpenID login with the RP using

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

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

Reply via email to