PROPOSAL: OpenID Authentication Flow and how delegate fits in

[Dick Hardt]

No, I am just pointing out that the openid.delegate is not needed by  
the RP.

I think documenting the flow this way is simpler, and fulfills the  
requirements that I have been seeing on the list.

-- Dick

On 10-Oct-06, at 12:47 AM, Drummond Reed wrote:

> Dick,
>
> 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)?
>
> =Drummond
>
> -----Original Message-----
> 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:
> 	OpenID URL
> 	iname
> 	IdP URL
>
> 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
> releasing.
> + 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
> http://openid.net/mailman/listinfo/specs
>
>