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. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs