[OpenID] Calling OpenID 2.0editors(wasRE:ProblemswithOpenIDand TAG httpRange-14)

[Drummond Reed]

> > On Thu, Mar 13, 2008 at 12:45:09PM -0700, Drummond Reed wrote:
> > Noah, as Eddy points out, if you consider this a problem, you can fix
> this
> > by instructing your OP to return <http://bytesexual.org/> as your
> > claimed_id.
> 
> On Friday, March 14, 2008 4:43 AM Noah Slater wrote:
> As I have previously replied in this thread, this is false if the OpenID
> specification specifically requires URIs to be canonicalised in this way.
> 
> Am I correct in my understanding that this canonicalisation is part of the
> spec?

I must be missing something. In your scenario you originally signed in to
the RP with <http://bytesexual.org/>, and you wanted to end out with is that
same identifier as your claimed_id. We were just pointing out a way to do
this. No canonicalization involved.

> > I continue to believe that when you say, " All this talk of XRIs, URNs
> and
> > URLs is beside the point...", you are missing the point that, when it
> comes
> > to identifying a real-world user, OpenID is dealing with a level of
> abstract
> > identifiers that operate on top of the layer of concrete identifiers
> used at
> > the HTTP protocol level.
> 
> Can you provide me with a citation from a standards body that explains or
> specifies the difference between abstract and concrete identifiers. In my
> experience of WebArch I have not come across any distinction between
> abstract
> and concrete identifiers and the HTTP RFC makes no such provisions.

The HTTP RFC would not make any such provisions since it does't deal with
abstract identifiers, any more than the TCP/IP specs make any provisions for
DNS names. Abstract identifiers by definition operate on a layer of
abstraction above the transport protocols used to resolve them.

The classic example of abstract identifiers is URNs. See RFCs 1737 and 2141
and http://en.wikipedia.org/wiki/Uniform_Resource_Name. URN architecture
does not to my knowledge use the term "abtract identifier" -- that was
introduced by the OASIS XRI Technical Committee, which I believe is the
primary place that work on abstract identifiers is happening now. For a
definition of abstract identifiers see the beginning of the XRI Syntax 2.0
specification (http://www.oasis-open.org/committees/download.php/15377) and
the glossary in Appendix A.

> > The fact that you can fix the problem you described by instructing your
> OP to
> > assert a different identifier than the one your RP is ultimately
> redirected to
> [snip]
> 
> As previously mentioned, I can not reasonably be expected to ask my OP to
> break
> the OpenID specification at my whim if my understanding is correct that
> this is
> an explicit part of OpenID.

I think there must be a misunderstanding. Per section 10.1 of OpenID
Authentication 2.0, your OP can return your choice of OpenID identifier. 

  o  openid.claimed_id

         Value: (optional) The Claimed Identifier. "openid.claimed_id"
         and "openid.identity" SHALL be either both present or both
         absent.

         Note: The end user MAY choose to use an OP-Local Identifier as
         a Claimed Identifier.

         Note: If neither Identifier is present in the assertion, it is
         not about an identifier, and will contain other information in
         its payload, using extensions (Section 12).

   o  openid.identity

         Value: (optional) The OP-Local Identifier

         Note: OpenID Providers MAY assist the end user in selecting the
         Claimed and OP-Local Identifiers about which the assertion is
         made.  The openid.identity field MAY be omitted if an extension
         is in use that makes the response meaningful without it (see
         openid.claimed_id above).

For security reasons, if your OP returns a different openid.claimed_id than
the one on which the RP performed discovery, the RP MUST repeat discovery to
verify that that OP is authoritative for that openid.claimed_id.

> > is an example of how synonyms at the abstract identifier level do not
> > necessarily reflect redirects or other semantics at the HTTP level.
> 
> If I understand this correctly you are talking about "synonyms" of
> identifiers
> at the OpenID level and how this does not match with the semantics of
> identifiers at the HTTP level.
> 
> Yes, this is exactly my point. Where you see an explanation for the
> behaviour I
> see a problem. The OpenID concept of synonyms should match the low-level
> semantics of the protocols and standards that it builds upon.

That would be directly contrary to the whole point of abstract identifiers.
It would be like saying that delegation of DNS names was somehow tied to the
routing paths in IP addressing.

To make this unescapably clear, let's move from words to pictures:

	=============================================================
	       OPENID IDENTIFIER LAYER - ABSTRACT URLS AND XRIS
	=============================================================
						|
						| <-- Are resolved using
						|
						V
	=============================================================
	          HTTP LAYER - CONCRETE HTTP(S) URLS AND DNS
	=============================================================
						|
						| <-- Are resolved using
						|
						V
	=============================================================
	       	TCP/IP LAYER - CONCRETE IP ADDRESSES
	=============================================================

Again, you can no more require relationships between identifiers at the
abstract OpenID level to follow the relationships of identifiers at the HTTP
layer than you can require relationships between identifiers at the HTTP
level to follow the relationships of identifiers at the TCP/IP layer.

=Drummond