Yet Another Delegation Thread

[Drummond Reed]

Dick, the questions you raise are exactly the kinds of tradeoffs the editors
need to discuss on their telecon (I agree this issue could consume an entire
call). I doubt I can add anything more here, so I'll just wish you all
godspeed on the call.

=Drummond 

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Tuesday, October 24, 2006 10:07 PM
To: Drummond Reed
Cc: 'Recordon, David'; specs at openid.net
Subject: Re: Yet Another Delegation Thread

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.