RE: [xri] OpenID 2.1

Nika,

 

Thanks for these thoughts, as I think they
go to the heart of the issue: OpenID has its basis in HTTP and http: URIs, yet OpenID
fundamentally requires using these URIs as abstract identifiers –
identifiers for which metadata discovery is required. Since that was never a
requirement of http: URIs, some of OpenID’s innovations stretch the
capabilities of http: URIs.

 

XRIs were designed from the start to be
abstract identifiers, so they have several key capabilities, like discovery,
protocol-independence, synonymity, and persistent synonym support built-in. So XRI
identifiers is a natural for OpenID.

 

But XRI has had to design it’s own
solutions to some of the missing pieces in the HTTP layer, such as discovery. OpenID
has been able to borrow some of these solutions, but applying them to http:
URIs misses some of the features of XRIs.

 

The net net is that I agree with you that
the solution is not to make XRIs an optional part of OpenID discovery, but to
design the OpenID discovery layer so it cleanly and consistently deals with all
OpenID identifier types, and provides the discovery, synonymity, and security
characteristics desired of all OpenID identifiers.

 

=Drummond 

 

From: Nika Jones
[mailto:] 

Sent: Saturday, September 20, 2008
10:59 AM

To: OASIS XRI TC

Cc: David Recordon

Subject: Re: [xri] OpenID 2.1

 

All:

 

I'm wondering if the core reasoning of moving XRI resolution to an
extension spec is:

 

1.  XRI resolution requires Library implementors to jump through
hoops for Canonical ID verification

2. Library implementors have not jumped through these hoops very well,
so XRI is resolution has spotty results

3. XRI does not currently have a large user base, so why put
Library implementors through the hoops, and make the OpenID Spec look
bad based on their implementations of the process.

4. During the CanonicalID verification process
the identity which the user used is not displayed back to the user,
so there could be some confusion on the users part, as to if they are correctly
authenticating, "their" identity.

 

Any to add?

 

Whereas XRI Resolution "Built-in" to the OpenID Spec would
allow the following, "Built-in":

 

1. Support of a truly abstract identifier, as http:// schemed urls are
currently not purely abstract (and there are hoops made to allow them to appear
this way)

2. CanonicalID verification of multiple identities owned
by the same individual, which frees up the user to freely associate
identities not tied to an RP.

3. Enforces HTTPS security without the user needing to type in https:// 

4. Is a concept that can be easily transfered outside of the
http:// namespace.

 

Any to add?

 

Personal Thoughts

 

XRI's were designed as pure abstract identifiers from the
start, URIs have done a great job locating and serving resources, however used
as just identifying resources they don't have as many built-in
features to deal with that role. Such as the use of metadata around resources,
change of authority or loss of an identifier.

 

I believe building in the
base technological theories provided by XRI was a great,
forward thinking act by the spec authors.
Which unfortunately has not been implemented correctly by Library
creators, thus putting pressure to move XRI technologies to an extension. By
moving XRI identifiers to an extension spec the use of XRI would be
optional to implement. I wonder if this would be a step in the wrong
direction. 

 

There might be an example in what the XRDS-Simple folks
are experiencing with discovery on top of HTTP and URIs, HTTP is
a protocol which was not "fundamentally" designed to support
metadata retrieval. There are great "optional" methods of doing
discovery of metadata over HTTP, however the fear is that the
discovery protocol chosen could not *rely* on something which could
be optional. So now there is incredible effort to agree on the best
solution, none of which seems to really stand above another, on how
to implement metadata discovery.

 

However, I feel OpenID, "did the right thing," by including
some of the core resolution, discovery, canonical, ideas from XRI based
abstract identifiers in the latest spec.  After all OpenID could
be looked at as an decentralized,
abstract identity authentication layer, correct. This seems to be a
"fundamentally" sound idea in which future identity based
products using OpenID as an underlining technology. I would suggest keeping XRI
as part of the core, even as Library creators struggle
to implement abstract identifier based concepts. As they
say, "No Pain, No Gain."

 

Note: We're struggling too (witness the struggle at: http://sourceforge.net/projects/ouno-xri/)
*smile*

 

Questions

 

Because the XRDS specification may go through much more radical changes
in the upcoming months/years. Would OpenID think about breaking out discovery
as part of the OpenID 2.1 Spec? (I know John eluded to this in his questions...
but I didn't see a clear answer)

 

Is there a consensus among RPs/Library creators that XRI is just,
"too hard"? or is it just, "unnecessary"?

 

One of problems with https:// identifiers is
the potential loss of a domain name, thus loss of an identifier.
XRI at its core attempts to include solutions this problem. Are XRIs attempts
to solve the "loss" factor inadequate or unneeded?

 

I'll try to word this a politically correct as possible. If a user
education effort must be made to think of themselves as a URL (ie: https://me.yahoo.com/example.nika)
then could the same efforts be made in the direction of users thinking of
themselves as an abstract identifier (ie: @yahoo*example.nika) -- https:// seems to have too much history of a
"web" based scheme to make it truly abstract in
my opinion? It seems those efforts if pushed as part of the core spec
would benefit Library creators, users and the OpenID Spec, now and in
the future.

 

Conclusion

 

I must acknowledge the success and efforts that have gone into OpenID,
the spec and surrounding community,  up until this point. OpenID
is a cool, and needed technology, and I plan on using it regardless of the
outcome of this discussion.

 

Regards,

 

Nika Jones

 

 

On Sep 18, 2008, at 8:04 AM, John Bradley wrote:

Hey John,

Thanks for taking the
time to dig into this and I look forward to talking to all of you pretty
soon.  Some thoughts inline...

--David

On Wed, Sep 17, 2008 at 3:15 PM, John Bradley <> wrote:

Thoughts on openID 2.1 and XRI as an extension.

The more or less common view of extensions is that they are features exposed by
the OP in the XRDS document.

I'll agree that is how extensions have been written today, but I don't see why
it has to be that way.  Every existing extension is already an interaction
between the RP and OP with many being initiated by the RP.  While not
extensions, services like BotBouncer are clearly focused toward RPs.

 

The authentication
methods themselves can be thought of as extensions.

SAML-SSO and others can be described in the XRDS and used to provide a binding
between the user and the meta-data resource. 

In the case where:

1. A OP supports making an assertion about the claimed_ID as  a XRI or as
a http: URI.

2. The RP wants to choose on the format it presents the openid.claimed_id and
openid.identity to the OP in.

I can see that described as an extension in the XRDS.

I suppose, though I have the feeling something like this would still be quite a
ways off.

 

The extension notion is more problematic when it comes to the
Discovery.

Should openID have optional discovery mechanisms?

We currently have a number of options in 2.0

1. Rel links in a http document (Non XRDS)

2. A X-XRDS-Location header with a http(s) URI indicating the location of the
XRDS

3. A HTML head element containing a <meta> element with a http-equiv
attribute equals to X-XRDS-Location where the content is a  http(s) URI
indicating the location of the XRDS

4. A HTTP GET request containing an Accept header specifying content type
application/xrds+xml. Returning the XRDS.

5. XRI resolution.

Yes, many different options with some being adopted and others not.  I
think we must look at how these different methods are being adopted.

 

At one point there was the notion of a Yadis ID and that ID http(s) or
XRI had some number of authentication services associated with it.

I think there are two questions to be asked.

1.  What is the discovery protocol or protocols  that openID RPs will
support

2.  What identifiers will openID the authentication protocol support.

Currently other than for discovery openID 2.0 largely treats identifiers as
opaque strings.

The XRI notion of polymorphism is currently achieved by using the CID as the
claimed_id however most clients strip the fragment from the claimed_id and use
it for display.

The 2.0 spec also specifies that the claimed_id and the identity sent to the OP
must be the same unless there is a LocalID in the XRDS.

This prevents OPs from displaying the iName the user input at the RP.

Some of the advantages of XRI just are not represented in the basic concepts of
the 2.0 spec.

Agreed, OpenID Auth 2.0 today doesn't do a good job supporting all of the
features offered by XRIs.  I unfortunately don't see this radically
changing in the core specification until XRI shows that it is really going to
be adopted for consumer identity online.

 

The only way to leave room for XRI or other identifier formats in the
core spec would be to make all of the identifiers abstract,  allow for the
claimed_id to be different from the current login identifier etc.

If that abstraction is not part of the core spec then we are better off giving
up on polymorphism for openID RPs and treat all XRI as HXRI for the purpose of
openID and make the new version of XRDS-Simple discovery end HXRI proxy
discovery equivalent for openID.

OpenID treats them all as https: URI and call it a day.

That might be the best approach.  In anycase, breaking XRI support out
into an extension allows it to be revised and evolved at a different rate than
the core specification.

 

I will throw out the heretical idea that Discovery and authentication
aught to be separate but modular specs.

We've talked about this in the past though I see it dramatically increasing the
scope of OpenID Auth 2.1 and making it more difficult for 95% of implementors
to follow the specification.

 

The RP of the future supports a Discovery Protocol for identifiers.

That discovery protocol supports some number of authentication mechanisms.

The RP selects the best authentication protocol for it purposes.

I like that sort of model, though don't think we're quite there yet. :)

 

XRI is in the identifier
and meta-data discovery for "non-information resources" business.

XRI identifiers have abstraction qualities not easily achieved with http:
identifiers.

The question is will there be a higher level identity abstraction for RPs that
deals with oAuth, openID, SAML-SSO, LID, info-card?

Things to think about for tomorrows call.

John Bradley

=jbradley

PS Johannes can be right about some things:)