Consolidated Delegate Proposal

Dick Hardt dick at sxip.com
Tue Oct 10 19:22:45 UTC 2006


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

>>> Josh Hoyt wrote:
>>>
>>> If I understand it correctly, this is identical to my original
>>> proposal[1]. I added rp_user_id because it prevents the IdP from
>>> having to do discovery when the RP has already done it. It is also a
>>> smaller change in the way that things work.
>>
>> The IdP cannot trust the RP's discovery. The IdP will have to make
>> sure that the IdP is authoritative for the identifier regardless.
>
> I went over that the other day with Josh. The reason the IdP can  
> trust the
> RP's discovery (which it does today in OpenID 1.1) is because the  
> RP is
> always authoritative for the identifier sent to the IdP. If the RP  
> asks for
> a different identifier, it's only spoofing itself.

This is true if the delegate is sent. This changes if the identifier  
is what the user types in.


>
>>> I am happy with either my original proposal (your proposal) or  
>>> having
>>> both fields in the request/response.
>>
>> My proposal was pretty much your proposal with a couple tweaks
>> (sorry, I should have listed these to make it clearer)
>>
>> - the IdP can return a different identity then the one the RP sent  
>> over
>>
>> - since the delegate is only used by the IdP, the spec can be
>> simplified (in fact, this can be out of band of the spec since it is
>> a protocol between the user and the IdP, the RP is not involved)
>
> I discussed this with Josh & the JanRain team, and our conclusion  
> was that
> If the protocol only supports one identifier parameter (currently
> openid.identity), then it can ONLY be either the RP-facing- 
> identifier, or
> the IdP-facing-identifier.

This terminology is confusing to me.

>
> That doesn't support any of the five motivations list at
> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, and it
> doesn't support Cases 1, 3, or 5 listed under "RP Rules for Identifier
> Parameters".

I think it works for (1) and (3)
(5) seems to be a documentation / lexicon issue

>
> If we've got it wrong there, and there is a way to do all of this  
> with one
> parameter, by all means do explain and we can finally close this  
> issue.

I thought I did explain it. :-)

I will explain it again in a separate post.



More information about the specs mailing list