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

Wed Mar 12 21:22:05 UTC 2008

Peter, RE your original question about "So, what is the Delegate OpenID
formally, once read from the metadata? Is it another class of URN?", my
answer would be "Yes, it is a synonym being asserted for the original URN."
It's an example of how the OpenID Authentication spec specifies identifier
synonyms at the abstract identifier level, vs. redirects at the concrete
locator level. In fact this fed back into the XRI Resolution 2.0 spec, where
we added the LocalID synonym element as a child of the Service element so
one of the four XRDS synonym elements (the other are EquivID, CanonicalID,
and CanonicalEquivID) could be used to assert an OpenID synonym with the
same semantics defined by OpenID Authentication.

One caveat about using the term "URN"- a formal URN must be a persistent
identifier that's never reassigned. While OpenID identifiers are abstract
identifiers like URNs, but only a subset of OpenID URLs would meet the
persistence requirements of URNs. The same is true of XRIs - reassignable
XRI "i-names" are not persistent, where persistent XRI "i-numbers" (that use
the ! syntax, like =!F83.62B1.44F.2813 or =!F83.62B1.44F.2813!1234) meet the
persistent requirements of URNs. That's why OpenID Authentication 2.0
specifies that if a user logs in with an XRI i-name, the RP must use the XRI
i-number asserted as the verified CanonicalID synonym as the Claimed
Identifier.

=Drummond 

  _____  

From: Peter Williams [mailto:pwilliams at rapattoni.com] 
Sent: Wednesday, March 12, 2008 12:41 PM
To: Drummond Reed; general at openid.net
Subject: RE: [OpenID] Calling OpenID 2.0 editors
(wasRE:ProblemswithOpenIDand TAG httpRange-14)

Actually, thinking more carefully about your email's model, perhaps I should
have said (concerning "concretization/resolution" of the URN ):

I'm happy with that: OpenIDs are a subclass of URN, constrained to have http
URL syntax (or XRI syntax). OpenID discovery is the process of transforming
the user supplied URN into the claimed ID URI.  (Note this final "URI", in
this rewrite).

My concern for a formal treatment of the Delegate OpenID still stands, tho.
Where present in metadata, the Delegate OpeniD will be used in the openid
auth message, as the claimed id. Yet the user is held accountable at the RP
as the "claimed ID URI" from the resolver. Its the claimed ID, not the
delegate OpenID, that gets account linked by the likes of plaxo, isn't it? I
could have two claimed ID mapping onto 1 plaxo account (by plaxo account
linking), where each of the Claimed IDs maps onto the same Delegate OpenID.

I supposed the likes of Plaxo could usefully enforce the rule that they
refuse to conclude Plaxo-account-linking two of a user's Claimed IDs unless
they have a common Delegate OpenID. Users providing user entered IDs can
then cite the particular "personality/role" that they wish to be
representing themselves as, to the RP.

OpenID is getting more interesting. We have (1) the idea that one OP can
cause the RP to hop to another OP (a referal, when acting itself as 2nd/Nth
level discovery agent). And (2), we have the other idea that Delegate
OpenIDs and RP obligations to manage delegateID<->claimedID mappings --
providing features analogous to some of the flows in the SAML2 nameid
protocol. We are indeed getting to quite a rich identity infrasrtucture.

  _____  

From: Peter Williams
Sent: Wed 3/12/2008 12:15 PM
To: Drummond Reed; general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors
(wasRE:ProblemswithOpenIDand TAG httpRange-14)

I'm happy with that: OpenIDs are a subclass of URN, constrained to have http
URL syntax (or XRI syntax). OpenID discovery is the process of transforming
the user supplied URN into the claimed ID URN. 

An OpenID/URN only has meaning only once its supported by suitable metadata
- obtained from the URN registry (one record of which is represented
concretely using an XRDs file)

So, what is the Delegate OpenID formally, once read from the metadata? Is it
another class of URN?

  _____  

From: Drummond Reed
Sent: Wed 3/12/2008 11:47 AM
To: 'Peter Williams'; 'Brendan Taylor'; general at openid.net
Subject: RE: [OpenID] Calling OpenID 2.0 editors
(wasRE:ProblemswithOpenIDand TAG httpRange-14)

Peter, it's a good point that OpenID explicitly deals with identifiers. To
be even more precise, OpenID explicitly deals with _abstract identifiers_ --
identifiers do not reference a resource directly, but only indirectly via
reference to a description of that resource. (URNs are a classic example of
abstract identifiers - http://en.wikipedia.org/wiki/Uniform_Resource_Name). 

Even though it's a URL, an OpenID URL is an abstract identifier because it
always resolves to another identifier (the OP URL). It can do that
resolution through an HTTP header, and HTML tag, or an XRDS document.

In the case of an OpenID XRI, it is by definition an abstract structured
identifier and resolves to a concrete identifier (or other metadata
describing the identified resource) via an XRDS document.

It's worth highlighting this because synonym management for abstract
identifiers takes place at a higher level than HTTP. For example, the XRI
Resolution 2.0 spec
(http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html) defines
four types of XRI synonyms that can be asserted in an XRDS document,
together with the synonym verification rules to prevent spoofing. OpenID
Authentication 2.0 takes advantage of this by specifying that if the user's
OpenID is an XRI, RPs MUST use the XRDS CanonicalID synonym (after
verification) as the user's Claimed Identifier. (The main reason for this -
preventing OpenID recycling -- is explained in detail in an ACM paper given
last week at the IDtrust Symposium -
http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds.
pdf). 

Although HTTP(S) is used for XRI resolution, the semantics of HTTP redirects
plays no part at all in determining or verifying XRI synonyms because these
synonym relationships are at the abstract identifier level and not the
concrete identifier level.

I think the same applies to OpenID URLs -- because they are abstract
identifiers, the synonym relationships are specified by the OpenID
Authentication spec and not by HTTP redirect semantics.

=Drummond 

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Peter Williams
> Sent: Wednesday, March 12, 2008 7:43 AM
> To: Brendan Taylor; general at openid.net
> Subject: Re: [OpenID] Calling OpenID 2.0 editors
> (wasRE:ProblemswithOpenIDand TAG httpRange-14)
> 
> 
> 
> 
> 
> OpenID, on the other hand, deals in identifiers. The documents involved
> are just a convenient way of figuring out what identifiers to use.
> 
> 
> 
> 
> Which is along the lines of what I said: we are not using http to collect
> web resources.
> 
> Openid does deal with identifiers, but they are not uris/urls in the
> formal sense of the uri rfc. Openid uses the syntax, but not the semantics
> - as to use the semantics would contradict the assumption above (uris
> identify web resources, including uri references that are resources in the
> semweb sense, in and of themselves)
> 
> We know the compliance argument has been dealt with : other upper layers
> have already done what openid discovery protocol does: ignore the link
> management semantics of http redirects.
> 
> This leaves the clickthru and the remembering issue - which is valid and
> pertinent. We could handle it openid.next by improving unsolicited auth,
> or standardizing openid discovery's use of redirects signals for openid
> purposes (only) when xris are not involved.
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080312/5fbc0880/attachment-0002.htm>