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

Wed Mar 12 19:40:32 UTC 2008

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/6ae67584/attachment-0002.htm>