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