[OpenID] XRDS multi-OP listing?

[Martin Atkins]

SitG Admin wrote:
>> It would be better to say "I'd like OP1, but only for PCs, and OP2 
>> for iPhones, ..." all somehow expressed in the XRDS file so the RP 
>> could do the redirect to the right OP based on which device I'm 
>> using, all while using the same identifier.
> 
> On a related note, I'd like it if the XRDS file could (optionally) 
> have multiple OP's identified in such a way that the RP *should* take 
> its cue to (if offering that feature) ask the user which OP they want 
> to use rather than redirecting them right away. I'm not sure but I 
> *think* XRDS would be the right place to start with this; the idea 
> being that, if I had an OP that used one-time-only passwords for 
> authentication, I'd want to save those pre-readied passwords for the 
> situations when I *really* wanted them, and otherwise use a "weaker" 
> OP.
> 

Again, I can get behind the use-case but I'm incredibly hesitant about 
making RPs do additional work. Turning a site into an RP is already a 
tough sell.

You got me thinking though about a way for the user (or someone on his 
behalf) host the selector himself. At a high level, the flow might be 
something like this:

  * User enters identifier at RP
  * RP finds that this identifier has an "provider selector", and 
redirects the user to the selector instead of to the provider directly.
  * The selector optionally displays some UI and then sends the user 
over to a selected OP.
  * The OP makes an assertion as normal. The identifier declares that 
the OP is allowed to make assertions for it, so authentication succeeds.

I consider this to essentially be an alternative version of delegation 
where the target of the delegation is determined dynamically rather than 
hard-coding it.

Legacy RPs would still see the standard OpenID service records and pick 
one via standard XRD priority rules. All of the possible providers must 
be listed for the last step above to succeed, so backward-compatibility 
is unavoidable.

The advantages of this are:
  * The provider selector is run by the user (or some sort of 
third-party on his behalf) rather than requiring each RP to implement 
its own selector. The implementation work for RPs is considerably 
reduced, and only users that have a requirement for multiple identity 
providers would need to worry about this extension.
  * The provider selector can use arbitrary mechanisms to select a 
provider. It might display a list and ask the user to choose one, or it 
might make a decision automatically based on (for example) a flag set by 
the RP saying that it's a mobile-oriented site. The selection mechanism 
can now be anything the user desires rather than requiring all 
mechanisms to be codified in a specification and implemented by each RP 
individually.

The main drawbacks I see are:
  * In the flow as I've described it, the initial indirection prevents 
the RP from pre-associating with the OP, and thus forces stateless mode. 
An adjustment to the flow could probably address this concern.
  * It introduces additional latency into the already-marginal OpenID 
transaction by adding at least two more redirects.
  * There is considerable overhead for a user to implement this vs. just 
adding some extra static stuff into the XRDS document. However, this 
could create a market for "delegation providers" that host delegation 
services on behalf of a user, and optionally host the associated 
delegating identity URL too.[1]
  * It creates an inconsistent user experiencebetween authenticating at 
RPs that support this extension vs. RPs that do not. I think this is 
inevitable for almost any OpenID extension, though.

I think this could be a path worth persuing to solve all of these 
multiple-OP use cases with a single extension.




------------------------------------------

[1] My thinking here is that there is now an opportunity for the 
delegation provider to introduce UI into the authentication flow, which 
opens up additional possible revenue opportunities. The most obvious 
example is putting banner ads on the provider selector page.