Non-browser Identity Verification

Martin Atkins mart at degeneration.co.uk
Wed May 18 02:24:56 PDT 2005


The current scheme is (as far as I can see) bound to the browser. If 
this is to become some amazing used-everywhere identity system, I think 
it's important to support non-browser-based auth too. I suspect it might 
already be supported in some sense, but let's think about it a little 
anyway.

An example of the kind of scenario I have in mind is a local application 
which will ultimately be submitting something to a server with an OpenID 
identity attached. For the sake of example, let's say that we're 
submitting some changes to MusicBrainz (<http://www.musicbrainz.org/>) 
from our media player, which is not a browser. In my hypothetical 
example world, MusicBrainz now allows OpenID identities to make changes 
without having to create a MusicBrainz account, and changes can be made 
both from the browser interface and through an API.

Of course, the system as currently designed relies on some token (which 
is probably a cookie) going to the identity server. If it's all 
happening server-side, this won't happen, so there still needs to be a 
client-side step where the user dances off to their identity server, 
proves they are the correct person by logging in, and thus approves the 
transaction. The client will be doing HTTP behind the scenes, but has no 
browser interface. It also probably won't have access to the browser's 
Cookies. What are the options here?

An obvious enhancement that springs to mind is to have the identity 
server request HTTP auth if it cannot identify the user by the included 
cookies. Since HTTP auth is machine-understandable, a client could then 
provide an interface to enter the relevant auth details and then 
everything else proceeds as normal.

Assuming I'm not missing something (which is possible, since I've not 
actually made any practical use of Yadis yet) once the authentication is 
complete the rest of the process can proceed as normal and the client 
can retain the digest to be submitted to the server later. In my 
modified scenario, the client application takes the role of the client 
and most of the helper, but the actual server behind the scenes will 
eventually do the key validation stuff before committing the changes.

Does this sound sensible, or have I missed an important detail?

As ever, alternative approaches are welcomed.


More information about the yadis mailing list