PROPOSAL: OpenID Authentication Flow and how delegate fits in
drummond.reed at cordance.net
Tue Oct 10 00:47:47 PDT 2006
While I think I followed most of what you say here, I'm not sure what the
exact proposal is. Are you proposing to remove the openid:delegate element
in 2.0? And replace it with an indirect identifier request protocol (your
step 3 below)?
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
Sent: Monday, October 09, 2006 10:15 PM
To: specs at openid.net
Subject: PROPOSAL: OpenID Authentication Flow and how delegate fits in
I'll start off with a couple new definitions so that we are not hung
up on what terms mean:
supplied_identifier := what the user types into the RP's form
verified_identifier := the identifier that the IdP says the user is
When looking at the OpenID protocol, the openid.identity sent from
the RP to the IdP can be thought of as just a hint as to what
verified_identifier the user wants to be at the RP. Given that, I
would describe the flow as such:
1) User provides a supplied_identifier to the RP. The user may type
this into a form which will post the supplied_identifier to the RP's
login_url or a software agent may post this to the login_url. The
supplied_identifier may be an:
2) The RP then does the appropriate discovery on supplied_identifier
to find the IdP's entry point and functionality supported. The
delegate tag is ignored if present.
3) If the RP wants to get a verified_identifier for the user, the RP
sends an indirect message to the IdP containing
openid.identity=supplied_identifier, otherwise openid.identity="none"
to indicate it does not want a verified_identifier.
4) if a verified_identifier was requested, the IdP determines which
verified_identifier the user would like to be with the RP, and then
sends an indirect message with openid.identity=verified_identifier
to the RP. Although the user may have typed in one OpenID URL or
iname, a different one could be in the response back to the RP.
5) If the RP has not already determined that the IdP is authorative
for verified_identifier, then the RP does discovery on the
verified_identifier to confirm the IdP is authoritative.
+ The IdP knows what the user typed into the form at the RP since
that is what is sent to the IdP.
+ The IdP can display a friendly name to the user as to what they are
+ The IdP can assist the user in determining which
verified_identifier they want to be at a site. Eg. the user may have
forgotten which verified_identifier they were in the past, and the
IdP can ask the user to confirm they want to use a different
verified_identifer then the one they have previously used.
+ works with OpenID 1.1 as even though a 1.1 RP will send the
delegate, a 2.0 IdP will send back the verified_identifier.
NOTE: The delegate tag is just a token that the user sticks into
their HTML so that the IdP knows the user controls that URL. If the
IdP controls the URL, then the delegate tag is not needed.
specs mailing list
specs at openid.net
More information about the specs