|David Recordon||Jun 4, 2008 2:08 pm|
|Hans Granqvist||Jun 4, 2008 2:34 pm|
|David Recordon||Jun 4, 2008 4:50 pm|
|Johannes Ernst||Jun 4, 2008 9:49 pm|
|Nat Sakimura||Jun 4, 2008 11:51 pm|
|Martin Atkins||Jun 5, 2008 12:02 am|
|Kick Willemse||Jun 5, 2008 3:49 am|
|Steven Livingstone-Perez||Jun 5, 2008 4:06 am|
|SitG Admin||Jun 5, 2008 8:31 am|
|Johannes Ernst||Jun 5, 2008 9:15 am||.gif, .gif|
|David Recordon||Jun 5, 2008 9:50 am|
|David Recordon||Jun 5, 2008 9:51 am|
|Martin Atkins||Jun 5, 2008 10:35 am|
|SitG Admin||Jun 5, 2008 12:42 pm|
|Martin Atkins||Jun 5, 2008 1:34 pm|
|SitG Admin||Jun 5, 2008 3:58 pm|
|Nat Sakimura||Jun 5, 2008 6:59 pm|
|Nat Sakimura||Jun 5, 2008 7:06 pm|
|Nat Sakimura||Jun 5, 2008 8:36 pm|
|Martin Atkins||Jun 6, 2008 12:06 am|
|Johannes Ernst||Jun 6, 2008 3:08 pm|
|Warren Jamison||Jun 6, 2008 6:05 pm|
|Carsten Pötter||Jun 6, 2008 8:47 pm|
|Brandon Ramirez||Jun 7, 2008 10:28 am|
|Brandon Ramirez||Jun 7, 2008 10:33 am|
|SitG Admin||Jun 7, 2008 9:22 pm|
|Tan, William||Jun 16, 2008 10:57 am|
|Subject:||[OpenID] XRDS multi-OP listing?|
|From:||Martin Atkins (ma...@degeneration.co.uk)|
|Date:||Jun 5, 2008 1:34:52 pm|
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. * 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.
 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.