Yet Another Delegation Thread

[Dick Hardt]

Thanks for the explanation Drummond. I think we need a con call on  
this topic alone ... :-)

On 24-Oct-06, at 6:16 PM, Drummond Reed wrote:
> * But in our discussion today, Josh and David and I boiled down the
> fundamental problem with the "single identifier on the wire"  
> solutions: as
> long as the RP has the ability to do the mapping between the Claimed
> Identifier and an IdP-specific Identifier (and there are many good  
> reasons
> to allow the RP to do this mapping, including that this is how  
> OpenID 1.1
> works),

Would you elaborate on those "good reasons"? I'd like to understand  
them because they are not obvious to me.

> then sending only one of these two identifiers on the wire to the
> IdP shuts down an option the IdP and/or user should have. To wit:
>
>   - If only the Claimed Identifier is sent, the IdP is forced to  
> repeat
> discovery if it doesn't recognize it (Josh and David and I believe  
> the IdP
> should not be forced to repeat discovery - it is not required in  
> OpenID 1.1
> and should not be required in OpenID 2.0).

The IdP does not do discovery in OpenID 1.1 because the IdP is not  
aware of the public identifier. The RP is doing it.

Either the IdP is binding the two identifiers, or the RP is doing it  
*after* getting them back unless it preserves state.

A design goal has been to move complexity to the IdP when given a  
choice.

>
>   - If only the IdP-specific Identifier is sent, then the IdP does  
> not have
> the option to assist the user with identifier selection based on  
> the Claimed
> Identifier (which is required for directed identity anyway, and is  
> one of
> the motivations behind this whole thread).

I don't think the RP needs to even understand the IdP-specific  
identifier.

>
> Our conclusion was that the only way to avoid shutting down one or  
> the other
> of these options is to allow (but not force) the RP to send both  
> identifiers
> using two parameters, and to have the IdP return both parameters,  
> which the
> RP must always verify based on its own discovery.
>
> That's the "state of the state" as of our discussion this afternoon.
> Hopefully this will be helpful input into the editor's call(s) this  
> week.

Thanks Drummond.