Gathering requirements for in-browser OpenID support

[Martin Atkins]

Robert Sayre wrote:
> Chris Messina wrote:
>> My suggestions about integrating OpenID (which could be done with
>> PasswordSafe as well) is that you'd login to your OpenID provider
>> using the Keychain app. This app would be able to pull down all the
>> services that you've authenticated against or have a relationship with
>> -- so that you have a convenient interface for managing those
>> connections. 
> 
> Interesting. Could we get a little more concrete with this idea? I think 
> I understand, but we should
> get a more detailed flow. How exactly would I login to my OpenID 
> provider with keychain?
> 

The way I've always imagined such a thing to work is to establish a 
protocol for the browser to talk directly to the IdP to obtain the 
signature, and then have the browser itself do the "redirect" back to 
the RP. It then also needs a way for the RP to declare that it supports 
OpenID login and give its return_to URL so that the browser can answer 
directly without having to go through a form.

This isn't a drastic change. The browser-to-IdP protocol can be an 
extension, and it doesn't even need to be a standard! The IdP can just 
say "install my plugin for happy fun time!" Of course, having it as a 
standard — separate to Auth 2.0, of course — would be better to avoid 
duplication of work, but there is the possibility of IdPs bootstrapping 
this themselves and using it as a selling point for their service.

The RP endpoint declaration *does* need to be a standard, of course; 
this has already been a requirement for several other proposals, so 
maybe a declaration of the RP endpoint URL should be a standalone 
extension in its own right, apon which other extensions can be built.


(Note that above where I say "the browser", I'm not excluding agents 
external to the browser that might come into play, such as Apple's 
keychain.)