Differentiating between User Identifier and OP Identifier

[Eran Hammer-Lahav]

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" /> 
    <Expires>2007-07-31T04:18:25.000Z</Expires> 
    <ProviderID>xri://=</ProviderID> 
    <LocalID priority="10">!6039.77F3.CF82.27A6</LocalID> 
    <CanonicalID priority="10">=!6039.77F3.CF82.27A6</CanonicalID> 

    <Service priority="10">
     <Type>http://specs.openid.net/auth/2.0/server</Type> 
     <URI>https://2idi.com/openid/</URI> 
    </Service>

    <Service priority="1">
     <Type>http://specs.openid.net/auth/2.0/signon</Type> 
     <URI>https://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 section
> - 7.3.

But not as clearly as in that section. 7.3.3 has the easiest text. I would
be nice to have one section describing the two possible elements, which
document type can have each one, and the order in which they should be used.
All the information is there - I agree, but I am not sure it reads easily
the first time.

> > 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.

EHL