PROPOSAL: OpenID Authentication Flow and how delegate fits in

Drummond Reed drummond.reed at
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)?


-----Original Message-----
From: specs-bounces at [mailto:specs-bounces at] On Behalf
Of Dick Hardt
Sent: Monday, October 09, 2006 10:15 PM
To: specs at
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

More information about the specs mailing list