Consolidated Delegate Proposal

Drummond Reed drummond.reed at cordance.net
Tue Oct 10 19:10:16 UTC 2006


>> 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.

>> 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. 

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".

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.

=Drummond 





More information about the specs mailing list