Can we have those conversations on the list so that everyone understands what the goals missed are?
I'd appreciate feedback on the revised proposal I emailed out and what is missing from it. -- Dick On 24-Oct-06, at 3:45 PM, Recordon, David wrote: > I honestly wasn't really putting it out as a proposal, rather > describing > more of the different cases involved in all of this. In any case, > talking this over more with Josh and Drummond it doesn't actually > accomplish all of the goals anyway. > > --David > > -----Original Message----- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Monday, October 23, 2006 11:04 PM > To: Drummond Reed > Cc: Recordon, David; specs@openid.net > Subject: Re: Yet Another Delegation Thread > > +1 > > Glad to see that we have settled on one identifier parameter > > On 23-Oct-06, at 7:07 PM, Drummond Reed wrote: > >> Here's another way to summarize the conclusions David and I >> reached in > >> our analysis today: >> >> 1) In OpenID Authentication 1.1, if there is a difference between the >> identifier the user wants to assert to an RP and the identifier the >> IdP wants to assert for the user (lets just call them ID1 and ID2), >> then the mapping from ID1 to ID2 can only be handled by the RP (using >> the OpenID delegate feature). >> >> 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP >> should also be able to handle the mapping between ID1 and ID2, and >> indeed in the directed identity use case, the IdP MUST handle this >> mapping. >> >> 3) What David and I realized today is that there are even use cases >> for BOTH the RP and IdP doing the mapping. In other words, even if an >> RP maps from >> ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to >> prevent the IdP from mapping ID2 to ID3 and passing ID3 back to >> the RP > >> (as long as the RP verifies the IdP is authoritative for ID3). >> Example: I log into RP using one URI#1, which maps in my XRDS >> document > >> to another IdP- specific URI#2, and then when logging into my IdP it >> reminds me that I previously used URI#3 at this RP, so I choose >> URI#3. >> >> 4) Therefore, as long as the protocol: a) REQUIRES the RP to do the >> mapping from ID1 to ID2 if present in the HTML or XRDS (which gives >> the user IdP-independent mapping if the user wants it), and b) ALLOWS >> the IdP to do the mapping from whatever identifier it receives >> (ID1 or > >> ID2) to whatever identifier it wants to assert on behalf of the user >> (ID3), then all use cases are supported. A user can take advantage of >> RP mapping, IdP mapping, or both. >> >> 5) This flexibility means that, with the rules David wrote, only one >> identifier parameter should be needed (although, as David suggests, a >> second parameter that is only a display hint from the RP to the IdP >> might be a help >> -- and I would argue that it could work in the other direction as >> well, but again only as a display hint.) >> >> =Drummond >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Recordon, David >> Sent: Monday, October 23, 2006 6:09 PM >> To: specs@openid.net >> Subject: Yet Another Delegation Thread >> >> So been going through all of this up in Seattle with Drummond and >> think I fully have my head around this. >> >> Thinking we have the following cases, which Draft 10 basically >> already > >> addresses. In any of the responses, the IdP MAY return a differing >> value for "openid.identity" than the RP requested. This obviously >> has >> varying degrees of usefulness depending on the specific situation. >> See >> below for "rules" RP must follow to protect itself from bogus >> assertions. >> >> 1) IdP Registered >> a) Entered http://user.myidp.com (IdP implicitly knows it >> owns) >> <URI> -> http://myidp.com/server.cgi >> >> Request >> openid.identity -> http://user.myidp.com >> Response >> openid.identity -> http://user.myidp.com >> >> b) Entered http://user.example.com (IdP has an out of band >> "registration" process where it verifies via discovery) >> <URI> -> http://myidp.com/server.cgi >> >> Request >> openid.identity -> http://user.example.com >> Response >> openid.identity -> http://user.example.com >> >> 2) Delegated (IdP knows nothing about what the user entered) >> a) Entered http://user.example.com >> <URI> -> http://myidp.com/server.cgi >> <OpenID:Delegate> -> http://user.myidp.com (IdP >> Controlled) >> >> Request >> openid.identity -> http://user.myidp.com >> Response >> openid.identity -> http://user.myidp.com >> >> b) Entered =user.example (or @2idi for Directed Identity case) >> <URI> -> http://myidp.com/server.cgi >> <OpenID:Delegate> -> http://user.myidp.com (IdP >> Controlled) >> >> Request >> openid.identity -> iNumber (LocalID ? <LocalID /> : >> <CanonicalID />) >> Response >> openid.identity -> iNumber >> >> 3) Directed Identity >> Entered http://myidp.com (IdP Registered) >> <URI> -> http://myidp.com/server.cgi >> <Type> -> http://openid.net/identifier_select/2.0 >> >> Request >> openid.identity -> http://openid.net/identifier_select/ >> 2.0 >> Response >> openid.identity -> http://user.myidp.com (IdP Registered, >> though not necessarily on same domain) >> >> >> I would argue, that this actually accomplishes what is needed; >> providing the following rules: >> 1) Before starting a transaction, the RP MUST validate that the >> IdP is > >> authoritative for the URI it is requesting an assertion about through >> the discovery process. >> >> 2a) If the RP ever receives a response value from IdP differing in >> the > >> URI assertion it requested, it MUST validate that the IdP is >> authoritative for that URI via the discovery process. This is due to >> that the IdP's response value for "openid.identity" does not have to >> be the same as the RP's request value in any of these three cases. >> >> 2b) In the Directed Identity case, the RP MUST always validate that >> the IdP is authoritative for the URI returned in its assertion via >> the > >> discovery process. >> >> So the one time that an additional parameter is useful, is in the >> Delegated Case where it would be useful to the IdP to know what the >> user entered at the RP. This has certain privacy implications, >> though > >> most of the data is public to begin with in terms of the HTML/XRDS >> semantics. >> There also is the concern that since the IdP is signing the response, >> it would have to also check that it is authoritative over this other >> parameter. If this is still a design goal, I'd propose we add >> "openid.display" (or whatever we want to call it) which the RP sends >> in the request solely to aid the IdP when interacting with the user. >> The IdP would then still make an assertion about the value of >> "openid.identity" and thus not return "openid.display" in the >> response. >> This thus continues placing the burden on the RP to verify all of the >> assertions made in the protocol. >> >> In the end this remains backwards compatible with 1.x, though also >> broadens the delegation model as Josh and Mart have previously >> described. This also places no additional burden on the IdP, >> since in > >> every case the RP is responsible for verifying that the IdP is >> authoritative for the assertion made. While the IdP should not make >> assertions that are not true, at the end of the day the RP should be >> verifying the validity of every assertion in any case to protect >> itself. >> >> --David >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs