Re: Differentiating between User Identifier and OP Identifier
On 30-Jul-07, at 8:48 PM, Eran Hammer-Lahav wrote: In this case, it sounds like an XRDS document MUST no include both an OP Endpoint element and a Claimed Identifier element. I don't see this implied anywhere. Do you have a specific pointer or a clear reasoning for this? If an XRDS has both elements, the RP will try the server and if it doesn't work for some reason (server down, etc.) it will move on to Yadis, not to the next signon service (7.3.2.2: If none is found, the RP will search for a Claimed Identifier Element). But an OP Identifier Element _was_ found, so the RP should not even process Claimed Identifier Elements, if they exist for whatever reason. It doesn't say if none is found or all server endpoints have been attempted and failed. Ok, so MUST is wrong in my statement. It should be: an XRDS document SHOULD not include both an OP Endpoint element and a Claimed Identifier element. The OpenID spec is not authoritative for what XRDS documents can or cannot contain; it just says how to consume them for the purposes of OpenID authentication. It's the other way around: the OP Identifier Element has higher priority, so the Claimed Identifier Element doesn't get used in such a case. In this example, the OP Identifier element has a lower XRDS priority than the Claimed Identifier Element. It's about the intention of the document author - this one says use sigon before server. The OpenID 2.0 spec implies, only use the priority value between services of the same element type. The Service type supersedes the priority attribute; priority is taken into account for services of the same type. This is what the protocol states, and the document's author intention does not override them ;-) Section 7.3.2.3 is confusing: 1. Does it only apply to XRI identifiers, not to XRDS documents found during Yadis discovery? Yes: When the identifier is an XRI Only because it goes on discussing XRDS documents. Does the last line about URL implies using Yadis to get to an XRDS document (where one would find a Canonical ID to ignore as instructed)? Yadis is used to get XRDS documents for URLs - not sure what you're asking here. The last sentence aims to answer the question what if I get a canonical id in an XRDS discovered from a URL. 4. The first line of the third paragraph is not needed. True, the same MUST is in the second phrase of the first paragraph. Is this email enough to have an editor consider/make the change? While not strictly needed, why is this particular reinforcement bad? 6. Last line is confusing. Where would a CanonicalID come from if using a URL identifier? This entire section is under XRDS discovery. Does it refer to the URL used in a Yadis discovery (I assume not)? What made you think a canonical id is needed for URLs? It is not -- for URLs the claimed identifier is determined as described in the normalization section. Exactly! So why is URL even mentioned here? See my point? :-) Sorry, no. The URL case is mentioned to answer the valid question above. Also, from HTML-Based discovery MUST be supported by Relaying Parties is sounds like XRDS discovery is not required. How do you come to this conclusion? See comments in previous email on XRI proxies. Those do not come to the same conclusion - while support for XRIs is left for each RP to decide, the same does not apply to the XRDS / Yadis discovery for URLs. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Differentiating between User Identifier and OP Identifier
The OpenID spec is not authoritative for what XRDS documents can or cannot contain; it just says how to consume them for the purposes of OpenID authentication. Point taken. As for the last few points, I now understand how all the little details from the various sections come together. I still like my idea of reorganizing section 7.3.2 a bit but it's not my call. I would suggest to word the last line in 7.3.2.3 to mention Yadis. Something like: When parsing an XRDS document retrieved during Yadis discovery (via a URL Identifier), the CanonicalID element MUST be ignored if present. Those do not come to the same conclusion - while support for XRIs is left for each RP to decide, the same does not apply to the XRDS / Yadis discovery for URLs. So XRI is optional? Thanks! EHL ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Differentiating between User Identifier and OP Identifier
Wow... this is a little too Da Vinci Code figuring this out form the spec... :-) Why not just write 'XRI is optional'? EHL -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Holsten Sent: Tuesday, July 31, 2007 8:55 PM To: Eran Hammer-Lahav Subject: Re: Differentiating between User Identifier and OP Identifier Eran Hammer-Lahav wrote: Those do not come to the same conclusion - while support for XRIs is left for each RP to decide, the same does not apply to the XRDS / Yadis discovery for URLs. So XRI is optional? Yes. http://josephholsten.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Differentiating between User Identifier and OP Identifier
On 28-Jul-07, at 10:00 AM, Eran Hammer-Lahav wrote: Section 7.3.1: If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] are to be applied. This somewhat confusing when combined with section 7.3.2.2: Once the Relaying Party has obtained an XRDS document, is MUST first search the document (following the rules described in [XRI_Resolution_2.0]) for an OP Identifier Element. It's the same thing, stated in two different places: 7.3 / 7.3.1 are an overview / introduction of the discovery process, while 7.3.2.2 is specific to the XRDS discovery. My confusion comes from the fact the spec is not clear about what makes a valid XRDS document used for OpenID discovery. Not sure 'valid' is the right term here. If the RP obtains an XRDS, it may or may not be able to extract an OP Identifier Element or a Claimed Identifier Element. If it can't, the RP is required to fall back to HTML discovery. In this case, it sounds like an XRDS document MUST no include both an OP Endpoint element and a Claimed Identifier element. I don't see this implied anywhere. Do you have a specific pointer or a clear reasoning for this? If it has both, and the Claimed Identifier Service Element has a higher priority, what does that mean? It's the other way around: the OP Identifier Element has higher priority, so the Claimed Identifier Element doesn't get used in such a case. Remove section 7.3.2.2 and move its content to the end of 7.3.2. It makes a better introduction to the two possible elements and their relationship. It would then use terms that have not been defined / explained yet (OP Identifier Element / Claimed Identifier Element). Section 7.3.2.3 is confusing: 1. Does it only apply to XRI identifiers, not to XRDS documents found during Yadis discovery? Yes: When the identifier is an XRI 2. It seems to only apply to Claimed Identifier Element - maybe it should merge into section 7.3.2.1.2? Yes, the canonical id is used only when there is a claimed identifier (an OP Identifier was not discovered). Not sure moving it would be good - the previous subsections outline the flow of processing the discovered information. Inserting the XRI / canonical id special case in the middle of it would make it harder to read / understand I believe. 3. It would be helpful to explain or reference how the RP can confirm the authorities listed in the 2nd paragraph. I read a couple of long threads on this list regarding this, but did not see a resolution. The XRI people are still working on it and the details should be available in the soon-to-be-published draft 12 of the XRI Resolution. Agree that a the XRI Resolution should be referenced from this paragraph. 4. The first line of the third paragraph is not needed. True, the same MUST is in the second phrase of the first paragraph. 5. The section briefly explains the CanonicalID tag, but not the ProviderID tag. A one line context of the ProviderID tag would help. 6. Last line is confusing. Where would a CanonicalID come from if using a URL identifier? This entire section is under XRDS discovery. Does it refer to the URL used in a Yadis discovery (I assume not)? What made you think a canonical id is needed for URLs? It is not -- for URLs the claimed identifier is determined as described in the normalization section. Section 7.3.2.4 says ...no longer used... but it is not clean where was it used before? The only spec I read prior this this one was the OpenID 1.1 which does not make use of XRDS documents. True, however there are OpenID 1.1 deployments that use Yadis / XRDS. (The openid namespace was used in Yadis for the delegate element.) Move the first paragraph of section 7.3.3 to the end of section 7.3.1. It will explain which discovery process is used for each of the possible identity types. This is outlined just before that, in the discovery overview section - 7.3. Also, from HTML-Based discovery MUST be supported by Relaying Parties is sounds like XRDS discovery is not required. How do you come to this conclusion? If this is true, it should be made much clearer and provide guidelines of the proper reply to the user when the RP only supports HTML discovery. It's false actually. Following the flow of discovery on the XRDS path, at 7.3 bullet 2 there is a SHALL (which is the same as REQUIRED). The statement above is in the HTML discovery section and applies only to HTML discovery. Not sure how / why you tend to apply or draw implications about the XRDS discovery from it. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Differentiating between User Identifier and OP Identifier
Thanks Johnny! In this case, it sounds like an XRDS document MUST no include both an OP Endpoint element and a Claimed Identifier element. I don't see this implied anywhere. Do you have a specific pointer or a clear reasoning for this? If an XRDS has both elements, the RP will try the server and if it doesn't work for some reason (server down, etc.) it will move on to Yadis, not to the next signon service (7.3.2.2: If none is found, the RP will search for a Claimed Identifier Element). It doesn't say if none is found or all server endpoints have been attempted and failed. Ok, so MUST is wrong in my statement. It should be: an XRDS document SHOULD not include both an OP Endpoint element and a Claimed Identifier element. It's the other way around: the OP Identifier Element has higher priority, so the Claimed Identifier Element doesn't get used in such a case. In this example, the OP Identifier element has a lower XRDS priority than the Claimed Identifier Element. It's about the intention of the document author - this one says use sigon before server. The OpenID 2.0 spec implies, only use the priority value between services of the same element type. ?xml version=1.0 encoding=UTF-8 ? XRDS ref=xri://=eran xmlns=xri://$xrds XRD xmlns=xri://$xrd*($v*2.0) Query*eran/Query Status code=100 / Expires2007-07-31T04:18:25.000Z/Expires ProviderIDxri://=/ProviderID LocalID priority=10!6039.77F3.CF82.27A6/LocalID CanonicalID priority=10=!6039.77F3.CF82.27A6/CanonicalID Service priority=10 Typehttp://specs.openid.net/auth/2.0/server/Type URIhttps://2idi.com/openid//URI /Service Service priority=1 Typehttp://specs.openid.net/auth/2.0/signon/Type URIhttps://2idi.com/openid//URI /Service /XRD /XRDS Remove section 7.3.2.2 and move its content to the end of 7.3.2. It makes a better introduction to the two possible elements and their relationship. It would then use terms that have not been defined / explained yet (OP Identifier Element / Claimed Identifier Element). Just add a reference to the sections below. It's done elsewhere in the document. It's a personal opinion. I think it reads better moved. Section 7.3.2.3 is confusing: 1. Does it only apply to XRI identifiers, not to XRDS documents found during Yadis discovery? Yes: When the identifier is an XRI Only because it goes on discussing XRDS documents. Does the last line about URL implies using Yadis to get to an XRDS document (where one would find a Canonical ID to ignore as instructed)? 2. It seems to only apply to Claimed Identifier Element - maybe it should merge into section 7.3.2.1.2? Yes, the canonical id is used only when there is a claimed identifier (an OP Identifier was not discovered). Not sure moving it would be good - the previous subsections outline the flow of processing the discovered information. Inserting the XRI / canonical id special case in the middle of it would make it harder to read / understand I believe. Not if you move 7.3.2.2 as suggested earlier... It will have the same logical flow but with a clearer association. 3. It would be helpful to explain or reference how the RP can confirm the authorities listed in the 2nd paragraph. I read a couple of long threads on this list regarding this, but did not see a resolution. The XRI people are still working on it and the details should be available in the soon-to-be-published draft 12 of the XRI Resolution. Agree that a the XRI Resolution should be referenced from this paragraph. Sounds good. I have a big TODO in my source code (the rest of the spec is up and running...). 4. The first line of the third paragraph is not needed. True, the same MUST is in the second phrase of the first paragraph. Is this email enough to have an editor consider/make the change? 6. Last line is confusing. Where would a CanonicalID come from if using a URL identifier? This entire section is under XRDS discovery. Does it refer to the URL used in a Yadis discovery (I assume not)? What made you think a canonical id is needed for URLs? It is not -- for URLs the claimed identifier is determined as described in the normalization section. Exactly! So why is URL even mentioned here? See my point? :-) Section 7.3.2.4 says ...no longer used... but it is not clean where was it used before? The only spec I read prior this this one was the OpenID 1.1 which does not make use of XRDS documents. True, however there are OpenID 1.1 deployments that use Yadis / XRDS. (The openid namespace was used in Yadis for the delegate element.) Maybe add a few words to say something about some existing implementations... Move the first paragraph of section 7.3.3 to the end of section 7.3.1. It will explain which discovery process is used for each of the possible identity types. This is outlined just before that, in the discovery overview
RE: Differentiating between User Identifier and OP Identifier
Thanks Johnny! It makes more sense now. Here are some further comments: I started to rewrite section 7 to make it easier to read but as I was going through it again and again, it became clearer. I think while all the terms are properly explained elsewhere, it might help to repeat some of them (like the two kinds of identifiers the user can provide) within the text. Here are some more specific comments and questions (I am not sure what's the process of suggesting changes to the draft). Obviously this is all meant as a suggestion so I will refrain from prefixing each comments with I would like to suggest (this might sound like a silly thing to say, but I really respect the work done by this group and would not want to offend anyone coming off too aggressive with instructions). Section 7.3.1: If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] are to be applied. This somewhat confusing when combined with section 7.3.2.2: Once the Relaying Party has obtained an XRDS document, is MUST first search the document (following the rules described in [XRI_Resolution_2.0]) for an OP Identifier Element. My confusion comes from the fact the spec is not clear about what makes a valid XRDS document used for OpenID discovery. In this case, it sounds like an XRDS document MUST no include both an OP Endpoint element and a Claimed Identifier element. If it has both, and the Claimed Identifier Service Element has a higher priority, what does that mean? Remove section 7.3.2.2 and move its content to the end of 7.3.2. It makes a better introduction to the two possible elements and their relationship. Section 7.3.2.3 is confusing: 1. Does it only apply to XRI identifiers, not to XRDS documents found during Yadis discovery? 2. It seems to only apply to Claimed Identifier Element - maybe it should merge into section 7.3.2.1.2? 3. It would be helpful to explain or reference how the RP can confirm the authorities listed in the 2nd paragraph. I read a couple of long threads on this list regarding this, but did not see a resolution. 4. The first line of the third paragraph is not needed. 5. The section briefly explains the CanonicalID tag, but not the ProviderID tag. A one line context of the ProviderID tag would help. 6. Last line is confusing. Where would a CanonicalID come from if using a URL identifier? This entire section is under XRDS discovery. Does it refer to the URL used in a Yadis discovery (I assume not)? Section 7.3.2.4 says ...no longer used... but it is not clean where was it used before? The only spec I read prior this this one was the OpenID 1.1 which does not make use of XRDS documents. Move the first paragraph of section 7.3.3 to the end of section 7.3.1. It will explain which discovery process is used for each of the possible identity types. Also, from HTML-Based discovery MUST be supported by Relaying Parties is sounds like XRDS discovery is not required. If this is true, it should be made much clearer and provide guidelines of the proper reply to the user when the RP only supports HTML discovery. Thanks, =eran ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Differentiating between User Identifier and OP Identifier
Hello, I am new to this group and OpenID in general so apologies if I repeat questions already asked here before. I did try to read a few months of backlog to catchup. I've spent the past 10 days implementing OpenID support for session authentication. I am currently working on an OpenId 2.0 RP implementation in C++ for a web service I am developing. The idea is to use OpenId to authenticate users' access to the API which is a framework enabling developers to build their own micro-blogging sites. Due to the nature of the platform, I am forced to implement the RP logic from scratch. The C++ libraries found are all 1.1, and I am not sure what is the state of the 2.0 libraries. I have been studying the spec and came up with a long list of issues and open questions mostly through implementation. I will post each question/issue separately to make it easier to track the threads and better archive the conversation. If this is annoying please let me know. This question is based on draft 11 of OpenID Authentication 2.0. Section 2 describe the User-Supplied Identifier, and section 3 bullet 2 provided the workflow, allowing users to provide a User Identity or an OP Endpoint ID. Section 7.3.1 provides a little more information but not much. The document is not very clear about the difference and how to decide what ID the user supplied. It is critical as the end of section 7.3.1 requires special value of the id fields to be used with an OP Endpoint. If the ID discovery leads to an XRDS document, I am guessing that if that document contains an OP Identifier element, it might mean that this is a server Id, but what if it also contains a claimed Id element? Is that not allowed? And in that case, is the Canonical Id ignored? But this theory only works for XRDS discovery. What about HTML discovery? Also, is there a difference in the handling of an XRDS discovery depending on how it was attained (XRI or Yadis)? Also, should I be using / referencing a newer version of the 2.0 draft? Thanks, Eran Hammer-Lahav (=eran) Hueniverse, LLC http://hueniverse.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
