OpenID 2.1

[John Bradley <jbradley@mac.com>]

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.

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.


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.

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.

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.


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

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.

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:)

smime.p7s