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
