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) > -> 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) > -> 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 > -> http://myidp.com/server.cgi > -> 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) > -> http://myidp.com/server.cgi > -> http://user.myidp.com (IdP > Controlled) > > Request > openid.identity -> iNumber (LocalID ? : > ) > Response > openid.identity -> iNumber > > 3) Directed Identity > Entered http://myidp.com (IdP Registered) > -> http://myidp.com/server.cgi > -> 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 respo
RE: Yet Another Delegation Thread
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) -> 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) -> 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 -> http://myidp.com/server.cgi -> 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) -> http://myidp.com/server.cgi -> http://user.myidp.com (IdP Controlled) Request openid.identity -> iNumber (LocalID ? : ) Response openid.identity -> iNumber 3) Directed Identity Entered http://myidp.com (IdP Registered) -> http://myidp.com/server.cgi -> 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 returne
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) -> 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) -> 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 -> http://myidp.com/server.cgi -> 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) -> http://myidp.com/server.cgi -> http://user.myidp.com (IdP Controlled) Request openid.identity -> iNumber (LocalID ? : ) Response openid.identity -> iNumber 3) Directed Identity Entered http://myidp.com (IdP Registered) -> http://myidp.com/server.cgi -> 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
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
No, that is the work-arroundThe solution is to have the email client assign fonts according to who is writing. Messages from Lord Rees-Mogg are written in an elegant Edwardian Copperplate. Paris Hilton uses BroadwayComments from Dick come in this font Sounds right to me. > -Original Message-> From: [EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]] On Behalf Of Dick Hardt> Sent: Sunday, October 22, 2006 5:00 PM> To: Kaliya Hamlin> Cc: specs@openid.net> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"> Style Identifiers>>> On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote:>> > For starters please don't use Comic Sans in professional> > correspondence. it is very hard to read (or take seriously)> http://> > bancomicsans.com/home.html>> Kaliya: The easy solution is to have your email program turn> all responses to plain text. :-)> ___> specs mailing list> specs@openid.net> http://openid.net/mailman/listinfo/specs>> ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [VOTE] Portable Identifier Support Proposal (patch)
On 23-Oct-06, at 12:27 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> Complexity: There is no reason for the RP to be managing the binding >> between the IdP and the portable identifier. Both the IdP and the RP >> are verifying this. There is no extra security, and more things to go >> wrong in an implementation. >> > > You keep stating that both the RP and the IdP are verifying this, but > under 1.1 at least this is not the case: the RP verifies the > delegation, > and the IdP is completely unaware of it. There is no need for the > IdP to > verify the delegation, since the RP will only harm itself if it > fails to > verify the relationship correctly. In the proposal, both the IdP and the RP verify. The IdP has to since the public identifier is now part of the message it is signing. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [VOTE] Portable Identifier Support Proposal (patch)
Dick Hardt wrote: > > Complexity: There is no reason for the RP to be managing the binding > between the IdP and the portable identifier. Both the IdP and the RP > are verifying this. There is no extra security, and more things to go > wrong in an implementation. > You keep stating that both the RP and the IdP are verifying this, but under 1.1 at least this is not the case: the RP verifies the delegation, and the IdP is completely unaware of it. There is no need for the IdP to verify the delegation, since the RP will only harm itself if it fails to verify the relationship correctly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
