SitG Admin wrote:

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.