Saw Gina Tripani’s followup post to Chriss Messina’s comments on This Week in Google.

http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/

It is very good to hear that people turns out to like the “delegation[1]” feature.

In the article Gina says:

I’m not sure yet how to set Idproxy as my “fallback” provider just yet; if you know how to do that, post it up in the comments.

John Bradley posted a reply there, but the sanitization of the comment system seem to be eating up important portions and making it hard to use. So, here is my attempt to explain it.

How to set up OpenID for your domain with fallback provider

(1) Create an XRDS file like this:

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
    <CanonicalID>http://xri.net/=!E18C.3B56.889D.850B</CanonicalID>
    <Service priority="10">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>https://authn.fullxri.com/authentication/</URI>
      <LocalID>http://xri.net/=!E18C.3B56.889D.850B</LocalID>
    </Service>
    <Service priority="20">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <URI>https://www.google.com/accounts/o8/ud?source=profiles</URI>
      <LocalID>http://www.google.com/profiles/sakimura</LocalID>
    </Service>
  </XRD>
</xrds:XRDS>

In it, each <Service> represent different authentication service.
In the above case, I am using Google as my failover authentication service (priority="20″) and fullxri as the second service (priority="10″) .

(2) Put the link to this file by inserting the following to the top page of your domain (You need to replace my domain to yours.

<meta http-equiv="X-XRDS-Location" content="http://www.sakimura.org/yadis.xml"></meta>

That’s all!

Unfortunately, not all RP libraries can to this failover. DotNetOpenAuth and JanRan’s library supports this feature.

[1] It is the delegation of the authentication service, not the delegation of your authorization decision.

Current draft of OAuth 2.0 http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ does not seem to define a standard way of defining “scopes”. It is totally Authorization Server dependent. If it were to act as a distributed system, this has to be standardized.

Also, the scope may require dynamic input parameters. The current spec draft does not specify it either. In fact, scope is nothing but the input parameter for the access_token right now.

The better approach, IMHO, is to define a generic way of what has been requested, instead of just defining proprietary “scope” strings.

For example, instead of defining an Authorization Server specific scope string for “Contact/Home”, define it as a generic registered string, such as “og”, so that one can specify it as

“og:email”,
“og:phone_number”,

etc. This is a much more granular way of giving permissions.

This has a side effect:

* The requests are longer

This is the rationale for having “request_url” for the flows.
One can put all the extension parameters in the “request_url”.

Defining an Extension Mechanism for both request and response would generally be useful.

Some basic design principles:

• No name space through type URI: fixed registered string for extensions.
  e.g., for Open Graph, perhaps use og:variable_names OR og_variable names
  where either “og:” or “og_” is the type prefix. (I kind of prefer ”:” over “_” as
  a separator since in CGI “-” and “_” will be identical, and in PHP GPC parameters
  ”.” and “_” are identical. Also, we are using “_” in the variable names already. )
• No cross interactions with other extensions

I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8.

Following is the strawman.

Simple, is it not?

For this to work out, there has to be a register of the prefix so that it will be unique. Where should the registry be is a good question.

One approach is to create a separate spec that lists all the OAuth extension prefixes.