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