Re: Consolidated Delegate Proposal
Keeping track of requirements does not imply a waterfall model to development, in my experience. It does imply being conscious of not adding requirements towards the end of the intended process unless absolutely necessary. It is that second item that I'm advocating. As the traffic on the list shows in recent days, it appears not all of us agree on slowing / freezing the list of requirements -- which is why we keep seeing proposals to add to the spec. On Oct 17, 2006, at 23:32, Dick Hardt wrote: On 17-Oct-06, at 2:10 PM, Johannes Ernst wrote: I think we need to come up with a decision making strategy that we can live with, and get the decision made. What about first, declaring a requirements freeze. I think one of the reasons that discussions go around in circles is because new requirements and use cases are being thrown at the specs, and naturally, the specs do not meet new requirements without further change. Would be easy if we had done use cases, then a requirements step, then write a spec. But there was not support for that. People just wanted to start drafting a spec and did not want any process. So we are where we are unfortunately. -- Dick Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Thanks Drummond, I think that clarifies where we are for me somewhat ... I have some thoughts on how we might move forward on bringing those world views inline that I will share tomorrow. Having looked over my recent posts, I am clearly not writing crisp, clear text at this point this evening. -- Dick On 18-Oct-06, at 12:02 AM, Drummond Reed wrote: > I don't think anything is missing from your previous posts, nor do > I think > you've missed anything from other's previous posts. I think we've > discussed > this issue thoroughly from all sides. > > As you say, "It is a different way of thinking about what OpenID is > doing". > In other words, it's a worldview thing. One worldview is that the > IdP should > handle all delegation/synonym management. Another worldview is that > the RP > can handle it in certain use cases and the IdP in others. The first > worldview requires only one identifier parameter. The latter > worldview works > better with two. > > When it comes down to a conflict in worldviews, there's no point in > further > technical debate. We just have to vote and move on. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Dick Hardt > Sent: Tuesday, October 17, 2006 10:59 PM > To: Recordon, David > Cc: specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > I don't see there being general consensus. > > I think Chris Drake was supportive of there being less disclosure as > well. > > Josh said it could be any of the three, but preferred two parameters. > > Brad did not really care. > > I do care and would like to see direct criticism on the explanation I > wrote about how the protocol works. > > It is a different way of thinking about what OpenID is doing, and I > think it is a useful view that makes it simpler. The RP does not need > to worry about the delegation mechanism. There is only one identifier > moving around. The concept that there is an RP identifier and an IdP > identifier is not needed. > > What is missing from my previous posts? Throw me a bloody bone here > so that I know what I am missing. > > -- Dick > > > On 17-Oct-06, at 3:20 PM, Recordon, David wrote: > >> I'm also echoing what Josh has said. There has been significant >> discussion on this issue and there seems to be general consensus, >> excluding Sxip, that the protocol should have two parameters. >> >> --David >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Josh Hoyt >> Sent: Tuesday, October 17, 2006 5:24 PM >> To: Dick Hardt >> Cc: specs@openid.net >> Subject: Re: Consolidated Delegate Proposal >> >> On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>>> 2. It is explicit what is going on from an implementation and >>>> specification perspective >>> >>> And I see the opposite. What the RP sends the IdP is just a hint. >>> What the IdP sends the RP is authoritative. >>> I see having two parameters as implying more meaning then is really >>> there. >> >> The IdP sending two identifiers *in the response* as the important >> part. >> The IdP is only authoritative *if discovery says it is*. There is no >> more meaning to the response than "I am asserting that when you do >> discovery, you will find that this information is true." What other >> meaning do you see? >> >>> Did you read what I wrote? Was there something you did not >>> understand? >> >>> Perhaps you can point out what you disagree about what I wrote? >> >> It's possible that I misinterpreted "the RP is figuring them out >> anyway." I took this as questioning why two identifiers is an >> improvement over the current (delegate only) model. >> >> My answer to this question was "it is explicit what is going on >> from an >> implementation and specification perspective." This statement was >> motivated by implementation experience and experience writing about >> this >> issue in OpenID 2 drafts. I believe that the two identifier approach >> will be easier. >> >> I also believe that if I had spent the time that I've spent arguing >> about this issue in documentation and implementation, the world >> would be >> better off, regardless of which of the three viable options for >> identifier portability had been chosen. >> >> I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-off
RE: Consolidated Delegate Proposal
I don't think anything is missing from your previous posts, nor do I think you've missed anything from other's previous posts. I think we've discussed this issue thoroughly from all sides. As you say, "It is a different way of thinking about what OpenID is doing". In other words, it's a worldview thing. One worldview is that the IdP should handle all delegation/synonym management. Another worldview is that the RP can handle it in certain use cases and the IdP in others. The first worldview requires only one identifier parameter. The latter worldview works better with two. When it comes down to a conflict in worldviews, there's no point in further technical debate. We just have to vote and move on. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 17, 2006 10:59 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Consolidated Delegate Proposal I don't see there being general consensus. I think Chris Drake was supportive of there being less disclosure as well. Josh said it could be any of the three, but preferred two parameters. Brad did not really care. I do care and would like to see direct criticism on the explanation I wrote about how the protocol works. It is a different way of thinking about what OpenID is doing, and I think it is a useful view that makes it simpler. The RP does not need to worry about the delegation mechanism. There is only one identifier moving around. The concept that there is an RP identifier and an IdP identifier is not needed. What is missing from my previous posts? Throw me a bloody bone here so that I know what I am missing. -- Dick On 17-Oct-06, at 3:20 PM, Recordon, David wrote: > I'm also echoing what Josh has said. There has been significant > discussion on this issue and there seems to be general consensus, > excluding Sxip, that the protocol should have two parameters. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Josh Hoyt > Sent: Tuesday, October 17, 2006 5:24 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> 2. It is explicit what is going on from an implementation and >>> specification perspective >> >> And I see the opposite. What the RP sends the IdP is just a hint. >> What the IdP sends the RP is authoritative. >> I see having two parameters as implying more meaning then is really >> there. > > The IdP sending two identifiers *in the response* as the important > part. > The IdP is only authoritative *if discovery says it is*. There is no > more meaning to the response than "I am asserting that when you do > discovery, you will find that this information is true." What other > meaning do you see? > >> Did you read what I wrote? Was there something you did not >> understand? > >> Perhaps you can point out what you disagree about what I wrote? > > It's possible that I misinterpreted "the RP is figuring them out > anyway." I took this as questioning why two identifiers is an > improvement over the current (delegate only) model. > > My answer to this question was "it is explicit what is going on > from an > implementation and specification perspective." This statement was > motivated by implementation experience and experience writing about > this > issue in OpenID 2 drafts. I believe that the two identifier approach > will be easier. > > I also believe that if I had spent the time that I've spent arguing > about this issue in documentation and implementation, the world > would be > better off, regardless of which of the three viable options for > identifier portability had been chosen. > > I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for > all of > them. You know which trade-offs I'd make. I know which ones you'd > make. > We just need to make a decision so that we can spend our energy and > time > on things that will make a difference to end-users. This is my last > word > on this list about this issue, unless there is significant insight. > I am > not going to change my votes. > > If you want to discuss it more off-list, I'm willing, but I think > that'd > just be wasting both of our time. > > Josh > ___ > 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
Re: Consolidated Delegate Proposal
On 17-Oct-06, at 2:10 PM, Johannes Ernst wrote: >>> I think we need to come up with a decision making strategy that >>> we can live >>> with, and get the decision made. > > What about first, declaring a requirements freeze. I think one of > the reasons that discussions go around in circles is because new > requirements and use cases are being thrown at the specs, and > naturally, the specs do not meet new requirements without further > change. Would be easy if we had done use cases, then a requirements step, then write a spec. But there was not support for that. People just wanted to start drafting a spec and did not want any process. So we are where we are unfortunately. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
I don't see there being general consensus. I think Chris Drake was supportive of there being less disclosure as well. Josh said it could be any of the three, but preferred two parameters. Brad did not really care. I do care and would like to see direct criticism on the explanation I wrote about how the protocol works. It is a different way of thinking about what OpenID is doing, and I think it is a useful view that makes it simpler. The RP does not need to worry about the delegation mechanism. There is only one identifier moving around. The concept that there is an RP identifier and an IdP identifier is not needed. What is missing from my previous posts? Throw me a bloody bone here so that I know what I am missing. -- Dick On 17-Oct-06, at 3:20 PM, Recordon, David wrote: > I'm also echoing what Josh has said. There has been significant > discussion on this issue and there seems to be general consensus, > excluding Sxip, that the protocol should have two parameters. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Josh Hoyt > Sent: Tuesday, October 17, 2006 5:24 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> 2. It is explicit what is going on from an implementation and >>> specification perspective >> >> And I see the opposite. What the RP sends the IdP is just a hint. >> What the IdP sends the RP is authoritative. >> I see having two parameters as implying more meaning then is really >> there. > > The IdP sending two identifiers *in the response* as the important > part. > The IdP is only authoritative *if discovery says it is*. There is no > more meaning to the response than "I am asserting that when you do > discovery, you will find that this information is true." What other > meaning do you see? > >> Did you read what I wrote? Was there something you did not >> understand? > >> Perhaps you can point out what you disagree about what I wrote? > > It's possible that I misinterpreted "the RP is figuring them out > anyway." I took this as questioning why two identifiers is an > improvement over the current (delegate only) model. > > My answer to this question was "it is explicit what is going on > from an > implementation and specification perspective." This statement was > motivated by implementation experience and experience writing about > this > issue in OpenID 2 drafts. I believe that the two identifier approach > will be easier. > > I also believe that if I had spent the time that I've spent arguing > about this issue in documentation and implementation, the world > would be > better off, regardless of which of the three viable options for > identifier portability had been chosen. > > I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for > all of > them. You know which trade-offs I'd make. I know which ones you'd > make. > We just need to make a decision so that we can spend our energy and > time > on things that will make a difference to end-users. This is my last > word > on this list about this issue, unless there is significant insight. > I am > not going to change my votes. > > If you want to discuss it more off-list, I'm willing, but I think > that'd > just be wasting both of our time. > > Josh > ___ > 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: Consolidated Delegate Proposal
I'm also echoing what Josh has said. There has been significant discussion on this issue and there seems to be general consensus, excluding Sxip, that the protocol should have two parameters. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, October 17, 2006 5:24 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: Consolidated Delegate Proposal On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > 2. It is explicit what is going on from an implementation and > > specification perspective > > And I see the opposite. What the RP sends the IdP is just a hint. > What the IdP sends the RP is authoritative. > I see having two parameters as implying more meaning then is really > there. The IdP sending two identifiers *in the response* as the important part. The IdP is only authoritative *if discovery says it is*. There is no more meaning to the response than "I am asserting that when you do discovery, you will find that this information is true." What other meaning do you see? > Did you read what I wrote? Was there something you did not understand? > Perhaps you can point out what you disagree about what I wrote? It's possible that I misinterpreted "the RP is figuring them out anyway." I took this as questioning why two identifiers is an improvement over the current (delegate only) model. My answer to this question was "it is explicit what is going on from an implementation and specification perspective." This statement was motivated by implementation experience and experience writing about this issue in OpenID 2 drafts. I believe that the two identifier approach will be easier. I also believe that if I had spent the time that I've spent arguing about this issue in documentation and implementation, the world would be better off, regardless of which of the three viable options for identifier portability had been chosen. I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for all of them. You know which trade-offs I'd make. I know which ones you'd make. We just need to make a decision so that we can spend our energy and time on things that will make a difference to end-users. This is my last word on this list about this issue, unless there is significant insight. I am not going to change my votes. If you want to discuss it more off-list, I'm willing, but I think that'd just be wasting both of our time. Josh ___ 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: Consolidated Delegate Proposal
On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > 2. It is explicit what is going on from an implementation and > > specification perspective > > And I see the opposite. What the RP sends the IdP is just a hint. > What the IdP sends the RP is authoritative. > I see having two parameters as implying more meaning then is really > there. The IdP sending two identifiers *in the response* as the important part. The IdP is only authoritative *if discovery says it is*. There is no more meaning to the response than "I am asserting that when you do discovery, you will find that this information is true." What other meaning do you see? > Did you read what I wrote? Was there something you did not > understand? Perhaps you can point out what you disagree about what I > wrote? It's possible that I misinterpreted "the RP is figuring them out anyway." I took this as questioning why two identifiers is an improvement over the current (delegate only) model. My answer to this question was "it is explicit what is going on from an implementation and specification perspective." This statement was motivated by implementation experience and experience writing about this issue in OpenID 2 drafts. I believe that the two identifier approach will be easier. I also believe that if I had spent the time that I've spent arguing about this issue in documentation and implementation, the world would be better off, regardless of which of the three viable options for identifier portability had been chosen. I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for all of them. You know which trade-offs I'd make. I know which ones you'd make. We just need to make a decision so that we can spend our energy and time on things that will make a difference to end-users. This is my last word on this list about this issue, unless there is significant insight. I am not going to change my votes. If you want to discuss it more off-list, I'm willing, but I think that'd just be wasting both of our time. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
I think we need to come up with a decision making strategy that we can live with, and get the decision made. What about first, declaring a requirements freeze. I think one of the reasons that discussions go around in circles is because new requirements and use cases are being thrown at the specs, and naturally, the specs do not meet new requirements without further change. I've been burning to add some of my own to the mix, but thought that in the interest of getting OpenID 2.0 authentication out the door, I decided to better not. (after all, there is always a 2.1...) What about if 2 significant "factions" disagree whether a given requirement is in scope or out of scope, it is out of scope for 2.0 -- that way, agreement may be easier to reach than the other way round; it's also a faster process. And such a "delayed" requirement will be first thing on the roadmap post 2.0. Just my 0.02 ... Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 17-Oct-06, at 11:15 AM, Josh Hoyt wrote: > On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> > It is, and must be, the relying party's responsibility to ensure >> that >> > the information in the response matches what is discovered. This is >> > true regardless when portable identifiers are used and when they >> are >> > not. It is true for all of the proposed delegation mechanisms. >> It is >> > really one of the fundamental elements of OpenID. >> > >> > A response from an IdP is meaningless until it is compared with the >> > discovered information for the identifier in question. >> >> If the RP is needing to make sure they match, then what is the point >> in sending both since the RP is figuring them out anyway? > > 1. IdP is not required to do discovery (more importantly, if an IdP > gets it wrong or is tricked, it is not treated as the authority on the > discovered information) I was not clear, what is the point in the IdP sending both if the RP is needing to make sure that they match? > > 2. It is explicit what is going on from an implementation and > specification perspective And I see the opposite. What the RP sends the IdP is just a hint. What the IdP sends the RP is authoritative. I see having two parameters as implying more meaning then is really there. Did you read what I wrote? Was there something you did not understand? Perhaps you can point out what you disagree about what I wrote? > It seems like this discussion is no longer constructive. It's a pretty > subtle issue, but I have not seen any new insight in a while. I think > we need to come up with a decision making strategy that we can live > with, and get the decision made. Well, I don't find that being constructive! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > It is, and must be, the relying party's responsibility to ensure that > > the information in the response matches what is discovered. This is > > true regardless when portable identifiers are used and when they are > > not. It is true for all of the proposed delegation mechanisms. It is > > really one of the fundamental elements of OpenID. > > > > A response from an IdP is meaningless until it is compared with the > > discovered information for the identifier in question. > > If the RP is needing to make sure they match, then what is the point > in sending both since the RP is figuring them out anyway? 1. IdP is not required to do discovery (more importantly, if an IdP gets it wrong or is tricked, it is not treated as the authority on the discovered information) 2. It is explicit what is going on from an implementation and specification perspective It seems like this discussion is no longer constructive. It's a pretty subtle issue, but I have not seen any new insight in a while. I think we need to come up with a decision making strategy that we can live with, and get the decision made. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 13-Oct-06, at 3:43 PM, Josh Hoyt wrote: > On 10/13/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: >> The IdP is issuing a signed assertion about these identifiers, I >> would assume the IdP to check the link between these identifiers. > > Sending two identifiers does not *prevent* the IdP from checking to > make sure they match. > >> What if a bad RP sends an auth request with a mismatched set and then >> re-posts the response to some other RP? I am sure someone will figure >> a way to exploit this. > > It is, and must be, the relying party's responsibility to ensure that > the information in the response matches what is discovered. This is > true regardless when portable identifiers are used and when they are > not. It is true for all of the proposed delegation mechanisms. It is > really one of the fundamental elements of OpenID. > > A response from an IdP is meaningless until it is compared with the > discovered information for the identifier in question. If the RP is needing to make sure they match, then what is the point in sending both since the RP is figuring them out anyway? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/13/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The IdP is issuing a signed assertion about these identifiers, I > would assume the IdP to check the link between these identifiers. Sending two identifiers does not *prevent* the IdP from checking to make sure they match. > What if a bad RP sends an auth request with a mismatched set and then > re-posts the response to some other RP? I am sure someone will figure > a way to exploit this. It is, and must be, the relying party's responsibility to ensure that the information in the response matches what is discovered. This is true regardless when portable identifiers are used and when they are not. It is true for all of the proposed delegation mechanisms. It is really one of the fundamental elements of OpenID. A response from an IdP is meaningless until it is compared with the discovered information for the identifier in question. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote: >>> Drummond wrote: >>> Since the RP has to do discovery on the i-name, the RP already >>> has the >>> i-number (CanonicalID). Further, as explained in previous >>> threads, the >>> CanonicalID is the primary key the RP wants to store for the user, >>> not the >>> i-name, because the i-number is forever while the i-name could >>> change. >>> >>> The RP is also motivated to send the i-number to the IdP for the >>> same reason >>> that the RP is motivated to send the delegate URL (if available): to >>> increase performance by saving the IdP from having to re-resolve >>> the i-name >>> (in the XRI case) or original URL (in the URL case). >> >> Dick wrote: >> >> Won't the IdP will still have to resolve the i-name? The IdP can't >> trust the RP, or know that the i-name and i-number are really linked >> unless it checks itself. > > There are no trust issues involved with the IdP using the > identifiers sent > by the RP. The RP is "relying" on the IdP, not vice versa. If the > RP sends > the wrong identifiers, it's fooling no one but itself. Thus the IdP > has no > reason to re-resolve (and good performance reasons not to). The IdP is issuing a signed assertion about these identifiers, I would assume the IdP to check the link between these identifiers. What if a bad RP sends an auth request with a mismatched set and then re-posts the response to some other RP? I am sure someone will figure a way to exploit this. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Use of i-numbers (was RE: Consolidated Delegate Proposal)
>Martin wrote: > >I think this is the intention, though it does show an interesting >inconsistency between the use of XRIs and the use of i-numbers. I >currently have three URL-based identifiers all pointing at the same >server and the same Yadis document, yet those identifiers are distinct. >However, in the comparable XRI case, it would appear that those >identifiers would all be considered to be the same. If they point to the exact same XRDS document with the same i-number as the CanonicalID, that would establish all three URLs and the CanonicalID i-number as synonyms (yes, it is possible to have URLs and XRIs that are synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new BackRef element that will enable an XRDS document to back reference any type of identifier that points to it, such as a URL, so you can machine-verify the back reference if you want. If you wanted to keep the three URLs as distinct, separate identities, point them at three different XRDS documents with different i-numbers. >I wonder how easy it is to get hold of new i-numbers. If they are >basically "throw-away" cheap, then I'm able to decide for myself how to >distribute my mappings to separate them. However, if these i-numbers are >going to be "expensive" (for some sense of the word) to aquire, I've got >less freedom in this respect. Drummond? The short answer is that delegated i-numbers (and this is the federated identifier meaning of the term "delegation") are as "throw-away" cheap as URL (at the path level), third-level DNS names, or any other form of delegated identifier. The "cost" is all in resolution, i.e., someone somewhere maintaining a registry that will point you to the XRDS document if you resolve it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Dick Hardt wrote: > > Won't the IdP will still have to resolve the i-name? The IdP can't > trust the RP, or know that the i-name and i-number are really linked > unless it checks itself. > The IdP is only authenticating the i-number. The i-name is for display to the user and possibly to allow the user to choose that as the display identity to send back to the RP. The only attacks possible are: * RP tries to "fool" the user into authenticating as a different i-number by sending a false i-name. I'm not sure what the benefit of this attack would be for the RP. * The RP tries to convince the IdP to send back an incorrect display identity back in the response. But then the RP is just fooling itself! The spec should probably contain some words to say that the IdP should not do any processing on the public identifier (whether it be a delegated HTTP URL or an XRI) that relies on the i-name to i-number mapping without first ensuring that the mapping is correct; any such processing would be outside of what is required for the Auth spec, though. Assuming for the moment that we've conceptually "separated the public identifier from the IdP token" per my proposal, the public (delegate) identifier or i-name is for the RP (it checks the mapping), and the IdP token (which is some URI that doesn't necessarily even have to be resolvable) is for the IdP. Both parties validate their own token; if either party doesn't validate its own token, it opens itself up to the other party telling lies. However, they do not have to authenticate *each-other*'s tokens. The RP's validation of its own token is defined by the spec. The IdP's authentication is not defined by the spec; the IdP doesn't necessarily even have to resolve its own tokens, but it can do if it wishes. >> Lastly, in the case where the identifier-the-RP-stores and the >> identifier-the-IdP-stores are different, if the RP has already >> discovered >> the latter, then the RP can be stateless by sending both to the >> IdP, knowing >> it will receive both back in the response. > > Then the RP is trusting the IdP will send back a correct mapping. This one bothers me too. Unless the RP can sign its initial request parameters to stop the IdP from tampering with them, I don't see how the RP can trust the IdP to return a correct mapping. My old stateless RP demo implementation just re-resolved this stuff when it got back the response to make sure that the IdP was telling the truth. I'd love to hear that this was unnecessary, since it did double the identity resolving overhead. > This discussion has me wondering about XRI resolution though. Given > that multiple i-names can resolve to the same i-number, just as > multiple domain names can resolve to the same IP address, and that > the i-name is the identifier the user sees, it would seem tht the i- > name is what should be stored by the RP, otherwise there is no > difference between using any of the i-names that resolve to the same > i-number, or is that the idea? I think this is the intention, though it does show an interesting inconsistency between the use of XRIs and the use of i-numbers. I currently have three URL-based identifiers all pointing at the same server and the same Yadis document, yet those identifiers are distinct. However, in the comparable XRI case, it would appear that those identifiers would all be considered to be the same. I wonder how easy it is to get hold of new i-numbers. If they are basically "throw-away" cheap, then I'm able to decide for myself how to distribute my mappings to separate them. However, if these i-numbers are going to be "expensive" (for some sense of the word) to aquire, I've got less freedom in this respect. Drummond? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
>> Drummond wrote: >> Since the RP has to do discovery on the i-name, the RP already has the >> i-number (CanonicalID). Further, as explained in previous threads, the >> CanonicalID is the primary key the RP wants to store for the user, >> not the >> i-name, because the i-number is forever while the i-name could change. >> >> The RP is also motivated to send the i-number to the IdP for the >> same reason >> that the RP is motivated to send the delegate URL (if available): to >> increase performance by saving the IdP from having to re-resolve >> the i-name >> (in the XRI case) or original URL (in the URL case). > >Dick wrote: > >Won't the IdP will still have to resolve the i-name? The IdP can't >trust the RP, or know that the i-name and i-number are really linked >unless it checks itself. There are no trust issues involved with the IdP using the identifiers sent by the RP. The RP is "relying" on the IdP, not vice versa. If the RP sends the wrong identifiers, it's fooling no one but itself. Thus the IdP has no reason to re-resolve (and good performance reasons not to). >> Lastly, in the case where the identifier-the-RP-stores and the >> identifier-the-IdP-stores are different, if the RP has already >> discovered >> the latter, then the RP can be stateless by sending both to the >> IdP, knowing >> it will receive both back in the response. > >Then the RP is trusting the IdP will send back a correct mapping. The is true no matter whether one or two or n identifiers are involved. In other words, even if the RP only sent the IdP one identifier (as OpenID 1.x does), if the IdP sends back the wrong identifier, the RP is screwed. >This discussion has me wondering about XRI resolution though. Given >that multiple i-names can resolve to the same i-number, just as >multiple domain names can resolve to the same IP address, and that >the i-name is the identifier the user sees, it would seem tht the i- >name is what should be stored by the RP, otherwise there is no >difference between using any of the i-names that resolve to the same >i-number, or is that the idea? That is the idea. Although it's tempting to think of multiple i-names mapping to the same i-number as being just like multiple domain names mapping down to the same IP address, in reality i-names and i-numbers are peers, and the mapping is "sideways" from the reassignable i-name synonyms to the persistent i-number synonym. So the real analogy would be multiple "temporary" domain names mapping as CNAMEs to one "permanent" domain name, and it's that "permanent" domain name (the i-number) that the RP wants to store. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 2:08 PM, Drummond Reed wrote: On 10/10/06, Dick Hardt wrote: [openid.rpuserid is the identifier] that the user gave the RP? >>> >>> Josh Hoyt wrote: >>> For URL identifiers, it is the supplied identifer, normalized, after >>> following redirects. In essence, it's the user's chosen identifier. >>> >>> For XRI identifers, it's the canonical ID (i-number). >> >> Dick Hardt wrote: >> >> This comment led me to want to make sure I understand the >> requirements of XRI. >> >> Q: why would the RP not want the i-name to come back rather then the >> i-number? >> >> The i-number can be derived from the i-name. The i-name is what is >> user visible. The IdP will make sure the i-name the user is >> presenting resolves to the i-number the user has presented in the >> past. >> >> Am I missing something? > > Since the RP has to do discovery on the i-name, the RP already has the > i-number (CanonicalID). Further, as explained in previous threads, the > CanonicalID is the primary key the RP wants to store for the user, > not the > i-name, because the i-number is forever while the i-name could change. > > The RP is also motivated to send the i-number to the IdP for the > same reason > that the RP is motivated to send the delegate URL (if available): to > increase performance by saving the IdP from having to re-resolve > the i-name > (in the XRI case) or original URL (in the URL case). Won't the IdP will still have to resolve the i-name? The IdP can't trust the RP, or know that the i-name and i-number are really linked unless it checks itself. > > Lastly, in the case where the identifier-the-RP-stores and the > identifier-the-IdP-stores are different, if the RP has already > discovered > the latter, then the RP can be stateless by sending both to the > IdP, knowing > it will receive both back in the response. Then the RP is trusting the IdP will send back a correct mapping. > If the RP can only send one > identifier to the IdP, it's stuck with a dilemma: > > * If the RP sends the identifier-the-RP-stores, then it forces the > IdP to > redo discovery, slowing performance. It would seem to me that the IdP still has to do discovery as it can't trust what the RP did, or that the RP even did it. Summary: sending both parameters does not save anything as both RP and IdP need to resolve the user presented Identifier to who is authoritative for it. This discussion has me wondering about XRI resolution though. Given that multiple i-names can resolve to the same i-number, just as multiple domain names can resolve to the same IP address, and that the i-name is the identifier the user sees, it would seem tht the i- name is what should be stored by the RP, otherwise there is no difference between using any of the i-names that resolve to the same i-number, or is that the idea? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > The IdP cannot trust the RP's discovery. The IdP will have to make > sure that the IdP is authoritative for the identifier regardless. The IdP doesn't have to trust the relying party's discovery. The IdP *can* make sure that it is authoritative for the rp_user_id, but if it isn't, the login will fail anyway. Only a malicious or broken RP will make a request with an identifier that does not point to that IdP. A malicious or broken RP does not need a meaningless assertion in order to pretend to have authenticated a user. The relying party is required to validate the assertion by doing discovery anyway, and there is no case for sending an identifier that does *not* delegate to that IdP, so why make the IdP do discovery again? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
>>> On 10/10/06, Dick Hardt wrote: >>> [openid.rpuserid is the identifier] that the user gave the RP? >> >> Josh Hoyt wrote: >> For URL identifiers, it is the supplied identifer, normalized, after >> following redirects. In essence, it's the user's chosen identifier. >> >> For XRI identifers, it's the canonical ID (i-number). > >Dick Hardt wrote: > >This comment led me to want to make sure I understand the >requirements of XRI. > >Q: why would the RP not want the i-name to come back rather then the >i-number? > >The i-number can be derived from the i-name. The i-name is what is >user visible. The IdP will make sure the i-name the user is >presenting resolves to the i-number the user has presented in the past. > >Am I missing something? Since the RP has to do discovery on the i-name, the RP already has the i-number (CanonicalID). Further, as explained in previous threads, the CanonicalID is the primary key the RP wants to store for the user, not the i-name, because the i-number is forever while the i-name could change. The RP is also motivated to send the i-number to the IdP for the same reason that the RP is motivated to send the delegate URL (if available): to increase performance by saving the IdP from having to re-resolve the i-name (in the XRI case) or original URL (in the URL case). Lastly, in the case where the identifier-the-RP-stores and the identifier-the-IdP-stores are different, if the RP has already discovered the latter, then the RP can be stateless by sending both to the IdP, knowing it will receive both back in the response. If the RP can only send one identifier to the IdP, it's stuck with a dilemma: * If the RP sends the identifier-the-RP-stores, then it forces the IdP to redo discovery, slowing performance. * If the RP sends the identifier-the-IdP-stores, then the RP cannot be stateless because it has to maintain a mapping between the identifier-the-RP-stores and the identifier-the-IdP-stores. In summary it boils down to this: * If the identifier-the-RP-stores and the identifier-the-IdP-stores are both the same, everything works fine with one identifier parameter, openid.identity. * However if the identifier-the-RP-stores and the identifier-the-IdP-stores are different, several efficiencies and optimizations are possible by enabling protocol messages to send and receive both the identifier-the-RP-stores (openid.rpuserid) and the identifier-the-IdP-stores (openid.identity) That's the proposal currently summarized at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
> Drummond wrote: >> >> Better still, if you could add it to the end of >> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and >> explain >> how the same motivations and use cases currently covered there >> (using two >> identifier parameters) can be satisfied just using openid.identity, >> that >> would help use consider everything in one place. > >Dick wrote: > >As I ponder this, I don't think that Proposal is a good starting >point, but I will elaborate more then I did last time and take a >different approach on explaining it. I understand if you don't want to use that proposal as a starting point. I'm just advocating that if you have a new proposal, putting it on the wiki and explaining it in a similar fashion so we can compare the two proposals side-by-side. I'm a big fan of wikis over email when it comes to closing issues (see http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 for an example of what we've been through to close (almost) all the issues for XRI Resolution 2.0 Working Draft 11 over the last two months). >Unfortunately it will not go out until later tonight or sometime >tomorrow as I have a string of meetings coming up now. Understood. I myself have meetings all day Wed/Thur, so I won't be able to spend as much time on this in that timeframe either. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> > RP user id is the identifier by which the relying party knows the >> > user. >> This is the one that the user gave the RP? > > For URL identifiers, it is the supplied identifer, normalized, after > following redirects. In essence, it's the user's chosen identifier. > > For XRI identifers, it's the canonical ID (i-number). This comment led me to want to make sure I understand the requirements of XRI. Q: why would the RP not want the i-name to come back rather then the i-number? The i-number can be derived from the i-name. The i-name is what is user visible. The IdP will make sure the i-name the user is presenting resolves to the i-number the user has presented in the past. Am I missing something? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 12:48 PM, Drummond Reed wrote: >>> Drummond wrote: >>> >>> 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. >> >> Dick wrote: >> >> I thought I did explain it. :-) >> >> I will explain it again in a separate post. > > Better still, if you could add it to the end of > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and > explain > how the same motivations and use cases currently covered there > (using two > identifier parameters) can be satisfied just using openid.identity, > that > would help use consider everything in one place. As I ponder this, I don't think that Proposal is a good starting point, but I will elaborate more then I did last time and take a different approach on explaining it. Unfortunately it will not go out until later tonight or sometime tomorrow as I have a string of meetings coming up now. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
>> Drummond wrote: >> >> 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. > >Dick wrote: > >I thought I did explain it. :-) > >I will explain it again in a separate post. Better still, if you could add it to the end of http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and explain how the same motivations and use cases currently covered there (using two identifier parameters) can be satisfied just using openid.identity, that would help use consider everything in one place. Thanks, =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Thanks David, but I don't think it is needed. In the flow that I proposed, I don't see that I need it, as I see that the delegate is only used by the IdP. What am I missing if anything? -- Dick On 10-Oct-06, at 4:47 AM, Recordon, David wrote: > Dick, > It is needed in the case where there is delegation with a URL, > openid.identity is the actual URL on the IdP and then > openid.rpuserid is > the URL that the user entered which delegates to openid.identity. > This > is then also used in the similar case with XRI delegation. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 4:51 AM > To: Drummond Reed > Cc: Recordon, David; specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > I am really unclear on why do we need both openid.identity and > openid.rpuserid? > > -- Dick > > On 10-Oct-06, at 12:47 AM, Drummond Reed wrote: > >> David, >> >> Based on feedback, I've backed openid.display out of the consolidated >> proposal at http://www.lifewiki.net/openid/ >> ConsolidatedDelegationProposal. >> >> This simplifies it to just two parameters, openid.identity and >> openid.rpuserid, which I believe now meet both Josh's and Martin's >> use > >> cases. >> >> =Drummond >> >> -----Original Message- >> From: Recordon, David [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 09, 2006 9:38 AM >> To: Drummond Reed; specs@openid.net >> Subject: RE: Consolidated Delegate Proposal >> >> In terms of openid.display, shouldn't the IdP greet the user in >> whatever manner it uses? Thus if the user has an account on the IdP, >> the IdP should always greet the user in the same manner with it. >> Seems like both a usability, phishing, and potential XSS issue if the >> IdP greets the user with a string from the RP. >> >> Am I just missing something there? >> >> --David >> >> -Original Message- >> From: Drummond Reed [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 09, 2006 1:20 AM >> To: Recordon, David; specs@openid.net >> Subject: RE: Consolidated Delegate Proposal >> >>> David Recordon wrote: >>> >>> Read through it >>> (http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >>> and I'm liking how it really clears up delegation. A few questions: >>> >>> 1) In case 1, is what the user typed in ever sent from the RP to the >>> IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered >>> their identifier on the RP? Or in the case where the IdP supports >>> multiple identifiers for the user, shouldn't the RP send what the >>> user entered so the user doesn't have to choose it again at their >>> IdP? >> >> Case 1 is the directed identity case. The RP *could* send what the >> user types in at the RP (the identifier for the IdP's directed >> identity server), but since the RP knows (from the OpenID service >> type) that this is an anonymous login, and thus that the RP needs to >> get openid.rd_user_id *back* from the IdP, it seemed better for >> the RP > >> not to send anything. This way you never break the rule that the IdP >> never changes any of the identifier parameters than an RP sends it. >> >>> 2) This may also be part of my first question, but why is there such >>> a delta between case 1 and cases 2 and 3? How does the RP know to >>> use case 1 versus case 2, they seem quite similar in their >>> explanation? >> >> Again, Case 1 is the directed identity case, that's why it's so >> unusual. >> The way the RP differentiates between case 1 and cases 2/3/4/5 is >> that > >> only in case 1 is the value attribute in the OpenID service >> endpoint "http://openid.net/identifier_select/2.0";. >> >> I went back and rewrote the page to make this much clearer. >> >>> 3) What is openid.display used for? >> >> The complete explanation was in the latter part of >> http://openid.net/pipermail/specs/2006-October/000278.html. But to >> make the consolidated proposal easier to review, I added a >> "Summary of > >> Motivations" >> section at the start and put a section at the end explaining the >> motivation for openid.display. >> >>> 4) In the rules, don't you mean the IdP must return the value of the >>> rp_user_id for the RP to key off of, not the
Re: Consolidated Delegate Proposal
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
RE: Consolidated Delegate Proposal
>> 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:58 AM, Josh Hoyt wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> 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 > > I question whether this is something we want to encourage. I think > it's a separate issue from the delegation mechanism. If the user wants > to choose an identifier, he'll use IdP-driven selection instead of > entering an identifier. I don't feel strongly about this, but I do > feel strongly that this should be decoupled from the delegation > discussion. I think this greatly simplifies the protocol and how it works > >> - 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) > > This was exactly my original proposal: > "A request for a delegated identifier and a request for a non- > delegated > identifier would be the same for the relying party, and the final, > verified identifier would always be included in the request/response." yes, that was in your proposal What I am saying is that we can remove significant discussion about delegate from the spec, and potentially remove it entirely ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> > RP user id is the identifier by which the relying party knows the >> > user. >> This is the one that the user gave the RP? > > For URL identifiers, it is the supplied identifer, normalized, after > following redirects. In essence, it's the user's chosen identifier. and I propose it could also be the IdP if that is what the user typed in > > For XRI identifers, it's the canonical ID (i-number). why not the i-name? then the IdP knows what the user wanted to be using. The IdP can get the i-number from the i-name, but not the reverse. > >> > "openid.identity" is the IdP user id. >> Where did this come from? > > When using delegation, it's the delegate value. Otherwise, it's the > same as the RP user id. It is identical to the way that the value for > "openid.identity" is currently used in OpenID 1 and the current draft > of OpenID 2. not sure I am seeing the value of sending both -- and from your last email, I think you are thinking the same, yes? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > 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 I question whether this is something we want to encourage. I think it's a separate issue from the delegation mechanism. If the user wants to choose an identifier, he'll use IdP-driven selection instead of entering an identifier. I don't feel strongly about this, but I do feel strongly that this should be decoupled from the delegation discussion. > - 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) This was exactly my original proposal: "A request for a delegated identifier and a request for a non-delegated identifier would be the same for the relying party, and the final, verified identifier would always be included in the request/response." Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > RP user id is the identifier by which the relying party knows the > > user. > This is the one that the user gave the RP? For URL identifiers, it is the supplied identifer, normalized, after following redirects. In essence, it's the user's chosen identifier. For XRI identifers, it's the canonical ID (i-number). > > "openid.identity" is the IdP user id. > Where did this come from? When using delegation, it's the delegate value. Otherwise, it's the same as the RP user id. It is identical to the way that the value for "openid.identity" is currently used in OpenID 1 and the current draft of OpenID 2. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:44 AM, Josh Hoyt wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I don't think the delegate needs to be moved. Please see >> http://openid.net/pipermail/specs/2006-October/000310.html > > 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 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) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Drummond Reed wrote: >> >> I was supportive of keeping the delegate from the IdP until I >> realized that the delegation was public knowledge and could not be >> hidden from the IdP. > > The same argument convinced me, too. If public XRDS documents are what we're > using to provide user control of identifier synonyms and thus provide > identifier portability -- which is the clearest and cleanest approach we've > seen -- then the best thing we can do from a privacy perspective is not > mislead users that they are protecting their privacy by using a "public" > OpenID identifier and a "private" identifier with their IdP. > Fair enough. I'm convinced. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
oops. Forgot footnote: 1. http://openid.net/pipermail/specs/2006-September/02.html On 10/10/06, Josh Hoyt <[EMAIL PROTECTED]> wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > I don't think the delegate needs to be moved. Please see > > http://openid.net/pipermail/specs/2006-October/000310.html > > 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. > > I am happy with either my original proposal (your proposal) or having > both fields in the request/response. > > Josh > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I don't think the delegate needs to be moved. Please see > http://openid.net/pipermail/specs/2006-October/000310.html 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. I am happy with either my original proposal (your proposal) or having both fields in the request/response. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
> Martin wrote: >> I'm surprised that our resident privacy advocates aren't making a >> bigger >> deal out of this. (If the privacy advocates have no problem then I'll >> let this go, since this isn't a use case I feel particularly strongly >> about myself.) > >Dick wrote: > >I was supportive of keeping the delegate from the IdP until I >realized that the delegation was public knowledge and could not be >hidden from the IdP. The same argument convinced me, too. If public XRDS documents are what we're using to provide user control of identifier synonyms and thus provide identifier portability -- which is the clearest and cleanest approach we've seen -- then the best thing we can do from a privacy perspective is not mislead users that they are protecting their privacy by using a "public" OpenID identifier and a "private" identifier with their IdP. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:29 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> Given that a Google of the delegate tag will yield all URLs >> containing it, >> there is no value in hiding delegation anymore. >> > > If I considered it important enough, I could restrict access to my > Yadis > document to only one party using various techniques, thus preventing > search engines and the IdP from reading the data inside. > > Admittedly, this is a lot more effort than most users are likely to > go to. I think that it is possible, but impractical -- and not sure it provides any advantage. The IdP knows you are going to the RP. It just does not know which Identifier you are using at the RP, but it does know the delegate that you are using. I'm not sure what significant information this hides from the IdP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 11:26 AM, Martin Atkins wrote: > Josh Hoyt wrote: >> On 10/10/06, Martin Atkins wrote: >>> Does the IdP really need to know what URL I gave to the RP? >>> >>> Earlier versions handled this adequately by the library including >>> implementer-defined variables in the return_to URL, which allows a >>> stateful RP to hide the real identifier behind a meaningless session >>> token, which satisfies Brad's criteria that the RP should be able to >>> hide from the IdP the fact that delegation is in use. >> >> see [1] where I addressed this question. I think that the benefits of >> having it there outweigh the benefit of hiding your identifier *from >> your chosen IdP*. The benefits for having it available to the IdP are >> the same as the benefits outlined in [2]. >> > > Trusting the IdP to do one thing (authenticate you) does not imply > that > you trust the IdP to do all things (for example, to know the > identifier > you used on a particular site.) perhaps, but it likely will > > While it's true that the IdP will know what RPs you have been signing > into (based on the return_to URLs) it will not necessarily be able to > track *what you do* on that site unless it knows what identifier you > used there. In sensitive situations, one can use a throw-away > identifier > that resolves only once and which only the RP need know about without > IdP involvement. I would envision that the IdP would be creating that throw away identifier. How would you propose it is created? > > Giving each party only the information it absolutely requires is a > good > general design principle, in my opinion. agreed, one of Kim's laws > > I'm not convinced that the directed identity case needs to work with > delegated identifiers, but even still there's nothing to stop an IdP > from giving the user the *option* of disclosing their delegated > identities through a configuration setting, thus giving the user the > choice about whether to trust the IdP with this information. > > I'm surprised that our resident privacy advocates aren't making a > bigger > deal out of this. (If the privacy advocates have no problem then I'll > let this go, since this isn't a use case I feel particularly strongly > about myself.) I was supportive of keeping the delegate from the IdP until I realized that the delegation was public knowledge and could not be hidden from the IdP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Dick Hardt wrote: > > Given that a Google of the delegate tag will yield all URLs > containing it, > there is no value in hiding delegation anymore. > If I considered it important enough, I could restrict access to my Yadis document to only one party using various techniques, thus preventing search engines and the IdP from reading the data inside. Admittedly, this is a lot more effort than most users are likely to go to. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Josh Hoyt wrote: > On 10/10/06, Martin Atkins wrote: >> Does the IdP really need to know what URL I gave to the RP? >> >> Earlier versions handled this adequately by the library including >> implementer-defined variables in the return_to URL, which allows a >> stateful RP to hide the real identifier behind a meaningless session >> token, which satisfies Brad's criteria that the RP should be able to >> hide from the IdP the fact that delegation is in use. > > see [1] where I addressed this question. I think that the benefits of > having it there outweigh the benefit of hiding your identifier *from > your chosen IdP*. The benefits for having it available to the IdP are > the same as the benefits outlined in [2]. > Trusting the IdP to do one thing (authenticate you) does not imply that you trust the IdP to do all things (for example, to know the identifier you used on a particular site.) While it's true that the IdP will know what RPs you have been signing into (based on the return_to URLs) it will not necessarily be able to track *what you do* on that site unless it knows what identifier you used there. In sensitive situations, one can use a throw-away identifier that resolves only once and which only the RP need know about without IdP involvement. Giving each party only the information it absolutely requires is a good general design principle, in my opinion. I'm not convinced that the directed identity case needs to work with delegated identifiers, but even still there's nothing to stop an IdP from giving the user the *option* of disclosing their delegated identities through a configuration setting, thus giving the user the choice about whether to trust the IdP with this information. I'm surprised that our resident privacy advocates aren't making a bigger deal out of this. (If the privacy advocates have no problem then I'll let this go, since this isn't a use case I feel particularly strongly about myself.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 10:23 AM, Josh Hoyt wrote: > On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I am really unclear on why do we need both openid.identity and >> openid.rpuserid? > > RP user id is the identifier by which the relying party knows the > user. This is the one that the user gave the RP? > "openid.identity" is the IdP user id. Where did this come from? > The IdP user id is the > "delegate" if one is present, or the same as the RP user id if it is > not. This is consistent with its current usage. I don't think the delegate needs to be moved. Please see http://openid.net/pipermail/specs/2006-October/000310.html > Having this field allows IdP-driven identifier selection to return an > assertion that works with a delegated identifier, since the IdP can > specify the RP user id that the user wants. > > It also allows the IdP to e.g. make persona selections based on the > way that the user identified himself to the RP. I think I am accomplishing all of that in my proposal, and I think it is much simpler and easier to understand. But I might be missing some capability. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10-Oct-06, at 10:18 AM, Martin Atkins wrote: > Recordon, David wrote: >> Dick, >> It is needed in the case where there is delegation with a URL, >> openid.identity is the actual URL on the IdP and then >> openid.rpuserid is >> the URL that the user entered which delegates to openid.identity. >> This >> is then also used in the similar case with XRI delegation. >> > > Does the IdP really need to know what URL I gave to the RP? > > Earlier versions handled this adequately by the library including > implementer-defined variables in the return_to URL, which allows a > stateful RP to hide the real identifier behind a meaningless session > token, which satisfies Brad's criteria that the RP should be able to > hide from the IdP the fact that delegation is in use. Given that a Google of the delegate tag will yield all URLs containing it, there is no value in hiding delegation anymore. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Martin Atkins <[EMAIL PROTECTED]> wrote: > Does the IdP really need to know what URL I gave to the RP? > > Earlier versions handled this adequately by the library including > implementer-defined variables in the return_to URL, which allows a > stateful RP to hide the real identifier behind a meaningless session > token, which satisfies Brad's criteria that the RP should be able to > hide from the IdP the fact that delegation is in use. see [1] where I addressed this question. I think that the benefits of having it there outweigh the benefit of hiding your identifier *from your chosen IdP*. The benefits for having it available to the IdP are the same as the benefits outlined in [2]. Josh 1. http://openid.net/pipermail/specs/2006-October/000170.html 2. http://openid.net/pipermail/specs/2006-September/02.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I am really unclear on why do we need both openid.identity and > openid.rpuserid? RP user id is the identifier by which the relying party knows the user. "openid.identity" is the IdP user id. The IdP user id is the "delegate" if one is present, or the same as the RP user id if it is not. This is consistent with its current usage. Having this field allows IdP-driven identifier selection to return an assertion that works with a delegated identifier, since the IdP can specify the RP user id that the user wants. It also allows the IdP to e.g. make persona selections based on the way that the user identified himself to the RP. Does that help? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Recordon, David wrote: > Dick, > It is needed in the case where there is delegation with a URL, > openid.identity is the actual URL on the IdP and then openid.rpuserid is > the URL that the user entered which delegates to openid.identity. This > is then also used in the similar case with XRI delegation. > Does the IdP really need to know what URL I gave to the RP? Earlier versions handled this adequately by the library including implementer-defined variables in the return_to URL, which allows a stateful RP to hide the real identifier behind a meaningless session token, which satisfies Brad's criteria that the RP should be able to hide from the IdP the fact that delegation is in use. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Dick, It is needed in the case where there is delegation with a URL, openid.identity is the actual URL on the IdP and then openid.rpuserid is the URL that the user entered which delegates to openid.identity. This is then also used in the similar case with XRI delegation. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:51 AM To: Drummond Reed Cc: Recordon, David; specs@openid.net Subject: Re: Consolidated Delegate Proposal I am really unclear on why do we need both openid.identity and openid.rpuserid? -- Dick On 10-Oct-06, at 12:47 AM, Drummond Reed wrote: > David, > > Based on feedback, I've backed openid.display out of the consolidated > proposal at http://www.lifewiki.net/openid/ > ConsolidatedDelegationProposal. > > This simplifies it to just two parameters, openid.identity and > openid.rpuserid, which I believe now meet both Josh's and Martin's use > cases. > > =Drummond > > -Original Message- > From: Recordon, David [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 9:38 AM > To: Drummond Reed; specs@openid.net > Subject: RE: Consolidated Delegate Proposal > > In terms of openid.display, shouldn't the IdP greet the user in > whatever manner it uses? Thus if the user has an account on the IdP, > the IdP should always greet the user in the same manner with it. > Seems like both a usability, phishing, and potential XSS issue if the > IdP greets the user with a string from the RP. > > Am I just missing something there? > > --David > > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 1:20 AM > To: Recordon, David; specs@openid.net > Subject: RE: Consolidated Delegate Proposal > >> David Recordon wrote: >> >> Read through it >> (http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >> and I'm liking how it really clears up delegation. A few questions: >> >> 1) In case 1, is what the user typed in ever sent from the RP to the >> IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered >> their identifier on the RP? Or in the case where the IdP supports >> multiple identifiers for the user, shouldn't the RP send what the >> user entered so the user doesn't have to choose it again at their >> IdP? > > Case 1 is the directed identity case. The RP *could* send what the > user types in at the RP (the identifier for the IdP's directed > identity server), but since the RP knows (from the OpenID service > type) that this is an anonymous login, and thus that the RP needs to > get openid.rd_user_id *back* from the IdP, it seemed better for the RP > not to send anything. This way you never break the rule that the IdP > never changes any of the identifier parameters than an RP sends it. > >> 2) This may also be part of my first question, but why is there such >> a delta between case 1 and cases 2 and 3? How does the RP know to >> use case 1 versus case 2, they seem quite similar in their >> explanation? > > Again, Case 1 is the directed identity case, that's why it's so > unusual. > The way the RP differentiates between case 1 and cases 2/3/4/5 is that > only in case 1 is the value attribute in the OpenID service > endpoint "http://openid.net/identifier_select/2.0";. > > I went back and rewrote the page to make this much clearer. > >> 3) What is openid.display used for? > > The complete explanation was in the latter part of > http://openid.net/pipermail/specs/2006-October/000278.html. But to > make the consolidated proposal easier to review, I added a "Summary of > Motivations" > section at the start and put a section at the end explaining the > motivation for openid.display. > >> 4) In the rules, don't you mean the IdP must return the value of the >> rp_user_id for the RP to key off of, not the value of identity? > > Yes, sorry, this was unclear. What I meant was that since the RP must > ALWAYS send openid.identity, the RP could *ALWAYS* count on this in > the response. > However you're right that as far as a persistent key goes > >> I think this is getting there, just either needs to be tightened up >> or the different flows better explained. > > I think it just needed to be better explained. Also, Josh, note that > when I went back to edit this tonight, I found the parameter name > "openid.rp_user_id" was driving the wiki markup nuts. So I changed it > to just "openid.rpuserid". Personally, I think this reads fine and > eliminates the awkward underscores. I hope you agree. > > =Drummond > > > > ___ > 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: Consolidated Delegate Proposal
I am really unclear on why do we need both openid.identity and openid.rpuserid? -- Dick On 10-Oct-06, at 12:47 AM, Drummond Reed wrote: > David, > > Based on feedback, I've backed openid.display out of the consolidated > proposal at http://www.lifewiki.net/openid/ > ConsolidatedDelegationProposal. > > This simplifies it to just two parameters, openid.identity and > openid.rpuserid, which I believe now meet both Josh's and Martin's use > cases. > > =Drummond > > -Original Message- > From: Recordon, David [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 9:38 AM > To: Drummond Reed; specs@openid.net > Subject: RE: Consolidated Delegate Proposal > > In terms of openid.display, shouldn't the IdP greet the user in > whatever > manner it uses? Thus if the user has an account on the IdP, the IdP > should always greet the user in the same manner with it. Seems like > both a usability, phishing, and potential XSS issue if the IdP greets > the user with a string from the RP. > > Am I just missing something there? > > --David > > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 1:20 AM > To: Recordon, David; specs@openid.net > Subject: RE: Consolidated Delegate Proposal > >> David Recordon wrote: >> >> Read through it >> (http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >> and I'm liking how it really clears up delegation. A few questions: >> >> 1) In case 1, is what the user typed in ever sent from the RP to the >> IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered >> their >> identifier on the RP? Or in the case where the IdP supports multiple >> identifiers for the user, shouldn't the RP send what the user entered >> so the user doesn't have to choose it again at their IdP? > > Case 1 is the directed identity case. The RP *could* send what the > user > types in at the RP (the identifier for the IdP's directed identity > server), but since the RP knows (from the OpenID service type) that > this > is an anonymous login, and thus that the RP needs to get > openid.rd_user_id *back* from the IdP, it seemed better for the RP not > to send anything. This way you never break the rule that the IdP never > changes any of the identifier parameters than an RP sends it. > >> 2) This may also be part of my first question, but why is there >> such a >> delta between case 1 and cases 2 and 3? How does the RP know to use >> case 1 versus case 2, they seem quite similar in their explanation? > > Again, Case 1 is the directed identity case, that's why it's so > unusual. > The way the RP differentiates between case 1 and cases 2/3/4/5 is that > only in case 1 is the value attribute in the OpenID service > endpoint "http://openid.net/identifier_select/2.0";. > > I went back and rewrote the page to make this much clearer. > >> 3) What is openid.display used for? > > The complete explanation was in the latter part of > http://openid.net/pipermail/specs/2006-October/000278.html. But to > make > the consolidated proposal easier to review, I added a "Summary of > Motivations" > section at the start and put a section at the end explaining the > motivation for openid.display. > >> 4) In the rules, don't you mean the IdP must return the value of the >> rp_user_id for the RP to key off of, not the value of identity? > > Yes, sorry, this was unclear. What I meant was that since the RP must > ALWAYS send openid.identity, the RP could *ALWAYS* count on this in > the > response. > However you're right that as far as a persistent key goes > >> I think this is getting there, just either needs to be tightened >> up or >> the different flows better explained. > > I think it just needed to be better explained. Also, Josh, note that > when I went back to edit this tonight, I found the parameter name > "openid.rp_user_id" was driving the wiki markup nuts. So I changed > it to > just "openid.rpuserid". Personally, I think this reads fine and > eliminates the awkward underscores. I hope you agree. > > =Drummond > > > > ___ > 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: Consolidated Delegate Proposal
David, Based on feedback, I've backed openid.display out of the consolidated proposal at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. This simplifies it to just two parameters, openid.identity and openid.rpuserid, which I believe now meet both Josh's and Martin's use cases. =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:38 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing, and potential XSS issue if the IdP greets the user with a string from the RP. Am I just missing something there? --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal >David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered >so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
I think a i-name IdP would have a display name for each i-name and show that consistent display name to the user. Why have the RP involved? I think this delegate stuff is getting over complicated. -- Dick On 9-Oct-06, at 3:06 PM, Drummond Reed wrote: > Dick, > > As Josh explains in > http://openid.net/pipermail/specs/2006-October/000296.html, the > primary > motivation for openid.display is when the user enters an i-name > into the RP. > As Josh puts it: > > "Basically, =foo and =bar could both be tied to the same i-number. > Doing > resolution on =foo and =bar will yield the same "canonical id," > which means > that they represent one logical entity. Drummond wants the display > name to > tell the IdP *which* synonym the user entered at the RP so that the > IdP can > present that same synonym in the UI, since the "canonical id" is both > the IdP user identifier and the RP user identifier, but is not > user-friendly (=!1234.1234.1234.1234)" > > It boils down to this: > > * If what the user enters at the RP is a URL, then there is at > least one and > at most two identifiers involved -- the Claimed Identifier and an > optional > Delegate Identifier. > * If what the user enters at the RP is an XRI, then there are at > least two > and at most three identifiers involved -- the Display Name (i- > name), the > Claimed Identifier (i-number -- "CanonicalID"), and an optional > Delegate > Identifier (which is usually the same CanonicalID but does not have > to be). > > Thus openid.display gives IdPs who support XRIs the ability to echo > back to > the user the i-name synonym they typed in at the RP, rather than by > their > CanonicalID i-number, which they are about as likely to know as > their IP > address. > > If we decide that's totally unnecessary -- that it's always okay > for an IdP > to just address an XRI user by an internal account name and not the > i-name > synonym they used at the RP -- then we can drop openid.display. > > =Drummond > > -----Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 2:19 PM > To: Drummond Reed > Cc: 'Josh Hoyt'; 'Recordon, David'; specs@openid.net > Subject: Re: Consolidated Delegate Proposal > > I have finally got up on this thread and don't see the value of the > openid.display parameter. > > The RP does not know who the user is when the user is using OpenID to > login, since that is why the RP is using OpenID, to find out who the > user is. > > Having the user type in another parameter just lets the user see the > same thing at the IdP. What's the point? > > The user clearly knows they are at two different sites, and I think > it is more important to have a consistent experience at the IdP > across RPs then to have a consistent experience between the RP and > the IdP. > > The IdP must know who the user is in order to create a positive > response back to the RP, so the IdP will already have some display > values to show the user. > > ... so what am I missing? > > -- Dick > > > On 9-Oct-06, at 10:56 AM, Drummond Reed wrote: > >> Josh, your message arrived while I was writing my reply to David's. >> >> I agree completely that openid.display is primarily useful for i-name >> synonyms. >> >> You go on to say, "For URIs, the display name *must* be the same as >> the RP >> user identifier, because there is no other value is verifiable by >> the IdP." >> >> I was proposing that openid.display be treated simply a string, so >> neither >> an RP nor an IdP would ever never resolve it, verify it, use it as >> key, etc. >> >> openid.display would default to openid.rpuserid if the RP didn't >> send an >> openid.display value. And if openid.rpuserid was a CanonicalID, >> then an RP >> SHOULD at least send the i-name as openid.display. >> >> However if the RP wanted to prompt a user for a short Display Name, >> even if >> the User's Claimed Identifier was a URL, the RP *could* send this >> Display >> Name to the IdP, and the IdP *could* display it so the user >> experience was >> consistent across the two sites. >> >> For example: >> >> At RP site the prompts are: >> >> OpenID Identifier: >> Your Preferred Display Name: >> >> The user enters: >> >> OpenID Identifier: example.idp.com/some/long/URL >> Your Preferred Display Name: DSR >> >> The RP sends to IdP: >> >> openid.identity = http:/
RE: Consolidated Delegate Proposal
Dick,
As Josh explains in
http://openid.net/pipermail/specs/2006-October/000296.html, the primary
motivation for openid.display is when the user enters an i-name into the RP.
As Josh puts it:
"Basically, =foo and =bar could both be tied to the same i-number. Doing
resolution on =foo and =bar will yield the same "canonical id," which means
that they represent one logical entity. Drummond wants the display name to
tell the IdP *which* synonym the user entered at the RP so that the IdP can
present that same synonym in the UI, since the "canonical id" is both
the IdP user identifier and the RP user identifier, but is not
user-friendly (=!1234.1234.1234.1234)"
It boils down to this:
* If what the user enters at the RP is a URL, then there is at least one and
at most two identifiers involved -- the Claimed Identifier and an optional
Delegate Identifier.
* If what the user enters at the RP is an XRI, then there are at least two
and at most three identifiers involved -- the Display Name (i-name), the
Claimed Identifier (i-number -- "CanonicalID"), and an optional Delegate
Identifier (which is usually the same CanonicalID but does not have to be).
Thus openid.display gives IdPs who support XRIs the ability to echo back to
the user the i-name synonym they typed in at the RP, rather than by their
CanonicalID i-number, which they are about as likely to know as their IP
address.
If we decide that's totally unnecessary -- that it's always okay for an IdP
to just address an XRI user by an internal account name and not the i-name
synonym they used at the RP -- then we can drop openid.display.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 2:19 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; 'Recordon, David'; specs@openid.net
Subject: Re: Consolidated Delegate Proposal
I have finally got up on this thread and don't see the value of the
openid.display parameter.
The RP does not know who the user is when the user is using OpenID to
login, since that is why the RP is using OpenID, to find out who the
user is.
Having the user type in another parameter just lets the user see the
same thing at the IdP. What's the point?
The user clearly knows they are at two different sites, and I think
it is more important to have a consistent experience at the IdP
across RPs then to have a consistent experience between the RP and
the IdP.
The IdP must know who the user is in order to create a positive
response back to the RP, so the IdP will already have some display
values to show the user.
... so what am I missing?
-- Dick
On 9-Oct-06, at 10:56 AM, Drummond Reed wrote:
> Josh, your message arrived while I was writing my reply to David's.
>
> I agree completely that openid.display is primarily useful for i-name
> synonyms.
>
> You go on to say, "For URIs, the display name *must* be the same as
> the RP
> user identifier, because there is no other value is verifiable by
> the IdP."
>
> I was proposing that openid.display be treated simply a string, so
> neither
> an RP nor an IdP would ever never resolve it, verify it, use it as
> key, etc.
>
> openid.display would default to openid.rpuserid if the RP didn't
> send an
> openid.display value. And if openid.rpuserid was a CanonicalID,
> then an RP
> SHOULD at least send the i-name as openid.display.
>
> However if the RP wanted to prompt a user for a short Display Name,
> even if
> the User's Claimed Identifier was a URL, the RP *could* send this
> Display
> Name to the IdP, and the IdP *could* display it so the user
> experience was
> consistent across the two sites.
>
> For example:
>
> At RP site the prompts are:
>
> OpenID Identifier:
> Your Preferred Display Name:
>
> The user enters:
>
> OpenID Identifier: example.idp.com/some/long/URL
> Your Preferred Display Name: DSR
>
> The RP sends to IdP:
>
> openid.identity = http://example.idp.com/some/long/URL
> openid.rpuserid = http://example.idp.com/some/long/URL
> openid.display = DSR
>
> The IdP displays:
>
> Hello DSR. Do you want to login to YourFriendlyRP?
> Password: []
> [Accept Once] {Accept Always] [Cancel]
>
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Josh Hoyt
> Sent: Monday, October 09, 2006 10:28 AM
> To: Recordon, David
> Cc: Drummond Reed; specs@openid.net
> Subject: Re: Consolidated Delegate Proposal
>
> On 10/9/06, Recordon, David <[EMAIL PROTECTED]> wrote:
>> In terms of openid.display, shouldn't the IdP greet the user in
>> whatever
>> manner it uses? Thus if the user has an account on the IdP, the Id
Re: Consolidated Delegate Proposal
I have finally got up on this thread and don't see the value of the
openid.display parameter.
The RP does not know who the user is when the user is using OpenID to
login, since that is why the RP is using OpenID, to find out who the
user is.
Having the user type in another parameter just lets the user see the
same thing at the IdP. What's the point?
The user clearly knows they are at two different sites, and I think
it is more important to have a consistent experience at the IdP
across RPs then to have a consistent experience between the RP and
the IdP.
The IdP must know who the user is in order to create a positive
response back to the RP, so the IdP will already have some display
values to show the user.
... so what am I missing?
-- Dick
On 9-Oct-06, at 10:56 AM, Drummond Reed wrote:
> Josh, your message arrived while I was writing my reply to David's.
>
> I agree completely that openid.display is primarily useful for i-name
> synonyms.
>
> You go on to say, "For URIs, the display name *must* be the same as
> the RP
> user identifier, because there is no other value is verifiable by
> the IdP."
>
> I was proposing that openid.display be treated simply a string, so
> neither
> an RP nor an IdP would ever never resolve it, verify it, use it as
> key, etc.
>
> openid.display would default to openid.rpuserid if the RP didn't
> send an
> openid.display value. And if openid.rpuserid was a CanonicalID,
> then an RP
> SHOULD at least send the i-name as openid.display.
>
> However if the RP wanted to prompt a user for a short Display Name,
> even if
> the User's Claimed Identifier was a URL, the RP *could* send this
> Display
> Name to the IdP, and the IdP *could* display it so the user
> experience was
> consistent across the two sites.
>
> For example:
>
> At RP site the prompts are:
>
> OpenID Identifier:
> Your Preferred Display Name:
>
> The user enters:
>
> OpenID Identifier: example.idp.com/some/long/URL
> Your Preferred Display Name: DSR
>
> The RP sends to IdP:
>
> openid.identity = http://example.idp.com/some/long/URL
> openid.rpuserid = http://example.idp.com/some/long/URL
> openid.display = DSR
>
> The IdP displays:
>
> Hello DSR. Do you want to login to YourFriendlyRP?
> Password: []
> [Accept Once] {Accept Always] [Cancel]
>
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Josh Hoyt
> Sent: Monday, October 09, 2006 10:28 AM
> To: Recordon, David
> Cc: Drummond Reed; specs@openid.net
> Subject: Re: Consolidated Delegate Proposal
>
> On 10/9/06, Recordon, David <[EMAIL PROTECTED]> wrote:
>> In terms of openid.display, shouldn't the IdP greet the user in
>> whatever
>> manner it uses? Thus if the user has an account on the IdP, the IdP
>> should always greet the user in the same manner with it. Seems like
>> both a usability, phishing, and potential XSS issue if the IdP greets
>> the user with a string from the RP.
>>
>> Am I just missing something there?
>
> The display name is only useful for XRI synonyms. Basically, =foo and
> =bar could both be tied to the same i-number. Doing resolution on =foo
> and =bar will yield the same "canonical id," which means that they
> represent one logical entity. Drummond wants the display name to tell
> the IdP *which* synonym the user entered at the RP so that the IdP can
> present that same synonym in the UI, since the "canonical id" is both
> the IdP user identifier and the RP user identifier, but is not
> user-friendly (=!1234.1234.1234.1234)
>
> For URIs, the display name *must* be the same as the RP user
> identifier, because there is no other value is verifiable by the IdP.
>
> Does that explanation help?
>
> Josh
>
> ___
> 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: Consolidated Delegate Proposal
Josh, your message arrived while I was writing my reply to David's.
I agree completely that openid.display is primarily useful for i-name
synonyms.
You go on to say, "For URIs, the display name *must* be the same as the RP
user identifier, because there is no other value is verifiable by the IdP."
I was proposing that openid.display be treated simply a string, so neither
an RP nor an IdP would ever never resolve it, verify it, use it as key, etc.
openid.display would default to openid.rpuserid if the RP didn't send an
openid.display value. And if openid.rpuserid was a CanonicalID, then an RP
SHOULD at least send the i-name as openid.display.
However if the RP wanted to prompt a user for a short Display Name, even if
the User's Claimed Identifier was a URL, the RP *could* send this Display
Name to the IdP, and the IdP *could* display it so the user experience was
consistent across the two sites.
For example:
At RP site the prompts are:
OpenID Identifier:
Your Preferred Display Name:
The user enters:
OpenID Identifier: example.idp.com/some/long/URL
Your Preferred Display Name: DSR
The RP sends to IdP:
openid.identity = http://example.idp.com/some/long/URL
openid.rpuserid = http://example.idp.com/some/long/URL
openid.display = DSR
The IdP displays:
Hello DSR. Do you want to login to YourFriendlyRP?
Password: []
[Accept Once] {Accept Always] [Cancel]
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
Sent: Monday, October 09, 2006 10:28 AM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: Consolidated Delegate Proposal
On 10/9/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> In terms of openid.display, shouldn't the IdP greet the user in whatever
> manner it uses? Thus if the user has an account on the IdP, the IdP
> should always greet the user in the same manner with it. Seems like
> both a usability, phishing, and potential XSS issue if the IdP greets
> the user with a string from the RP.
>
> Am I just missing something there?
The display name is only useful for XRI synonyms. Basically, =foo and
=bar could both be tied to the same i-number. Doing resolution on =foo
and =bar will yield the same "canonical id," which means that they
represent one logical entity. Drummond wants the display name to tell
the IdP *which* synonym the user entered at the RP so that the IdP can
present that same synonym in the UI, since the "canonical id" is both
the IdP user identifier and the RP user identifier, but is not
user-friendly (=!1234.1234.1234.1234)
For URIs, the display name *must* be the same as the RP user
identifier, because there is no other value is verifiable by the IdP.
Does that explanation help?
Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
No, you're not missing anything. That's what I thought at the outset too. And you may well be right -- the IdP can always use openid.identity to lookup the user's IdP account and retrieve an an internal display name from there. However I don't believe there's a security or phishing issue here -- the IdP would only echo the Display Name, if any, passed from the IdP. In other words, if the RP prompts for a Display Name, and the User enters one at the RP, then it's perfectly natural that the IdP can turn around and address the User by the same Display Name, since the IdP is authenticating the User's identity in the context of the RP. That doesn't mean the IdP can't also display it's own identifier(s) for the User if it wants (or other tokens that help prove to the User that they are not being phished). It's not just for i-names that openid.display is useful -- it's also handy for long URLs, where an RP is motivated to give the user a shorter display name to better control screen real estate. Anyway, those are the basic use cases. If there's not enough value in openid.display then we can drop it. openid.rpuserid is the meat of the proposal, because it enables a clean separation between the IdP-facing identifier (openid.identity) and the RP-facing-identifier (openid.rpuserid). =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:38 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing, and potential XSS issue if the IdP greets the user with a string from the RP. Am I just missing something there? --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal >David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered >so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/9/06, Recordon, David <[EMAIL PROTECTED]> wrote: > In terms of openid.display, shouldn't the IdP greet the user in whatever > manner it uses? Thus if the user has an account on the IdP, the IdP > should always greet the user in the same manner with it. Seems like > both a usability, phishing, and potential XSS issue if the IdP greets > the user with a string from the RP. > > Am I just missing something there? The display name is only useful for XRI synonyms. Basically, =foo and =bar could both be tied to the same i-number. Doing resolution on =foo and =bar will yield the same "canonical id," which means that they represent one logical entity. Drummond wants the display name to tell the IdP *which* synonym the user entered at the RP so that the IdP can present that same synonym in the UI, since the "canonical id" is both the IdP user identifier and the RP user identifier, but is not user-friendly (=!1234.1234.1234.1234) For URIs, the display name *must* be the same as the RP user identifier, because there is no other value is verifiable by the IdP. Does that explanation help? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Maybe I misunderstood the directed identity protocol. Section 4.2.3.1 of Draft 9 says: *** EXCERPT *** 4.2.3.1. IdP Identifiers If the entered Identifier is an IdP Identifier, the OpenID information is contained in a service element with the following information: * An tag whose text content is "http://openid.net/server/2.0"; * An tag whose text content is The IdP Endpoint URL *** END *** So in the discovery phase what the RP should find is an xrd:Type tag of "http://openid.net/server/2.0";. That's what I meant. Am I missing something? =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:34 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal Ok, that makes it more clear. I think this line was part of what was throwing me, "If Claimed Identifier is EITHER a URL or XRI that maps to a directed identity server (http://openid.net/server/2.0), the values are:" since in the discovery phase it should be finding the type of identifier_select. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal >David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered >so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing, and potential XSS issue if the IdP greets the user with a string from the RP. Am I just missing something there? --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal >David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered >so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Ok, that makes it more clear. I think this line was part of what was throwing me, "If Claimed Identifier is EITHER a URL or XRI that maps to a directed identity server (http://openid.net/server/2.0), the values are:" since in the discovery phase it should be finding the type of identifier_select. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal >David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered >so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
>David Recordon wrote: > >Read through it >(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), >and I'm liking how it really clears up delegation. A >few questions: > >1) In case 1, is what the user typed in ever sent from the RP to the >IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their >identifier on the RP? Or in the case where the IdP supports multiple >identifiers for the user, shouldn't the RP send what the user entered so >the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. >2) This may also be part of my first question, but why is there such a >delta between case 1 and cases 2 and 3? How does the RP know to use >case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value attribute in the OpenID service endpoint "http://openid.net/identifier_select/2.0";. I went back and rewrote the page to make this much clearer. >3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a "Summary of Motivations" section at the start and put a section at the end explaining the motivation for openid.display. >4) In the rules, don't you mean the IdP must return the value of the >rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes >I think this is getting there, just either needs to be tightened up or >the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name "openid.rp_user_id" was driving the wiki markup nuts. So I changed it to just "openid.rpuserid". Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Read through it, and I'm liking how it really clears up delegation. A few questions: 1) In case 1, is what the user typed in every sent from the RP to the IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their identifier on the RP? Or in the case where the IdP supports multiple identifiers for the user, shouldn't the RP send what the user entered so the user doesn't have to choose it again at their IdP? 2) This may also be part of my first question, but why is there such a delta between case 1 and cases 2 and 3? How does the RP know to use case 1 versus case 2, they seem quite similar in their explanation? 3) What is openid.display used for? 4) In the rules, don't you mean the IdP must return the value of the rp_user_id for the RP to key off of, not the value of identity? I think this is getting there, just either needs to be tightened up or the different flows better explained. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Friday, October 06, 2006 9:18 PM To: specs@openid.net Subject: Consolidated Delegate Proposal At David's suggestion, to make it easier to follow, I've posted what I believe is a consolidated delegate proposal at: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal This incorporates Josh's original, Martin's, Josh's amendment, and my amendment to Josh's. Josh and Martin, please look this over and either make changes or comment as needed. It will be wonderful to finally close this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
