Let me elaborate on the idea and requirements I have in mind. The use case I'm thinking of is perhaps not so much non-interactivity in particular as it is "login with no black boxes". Currently, the RP is supposed to delegate full control of the login process to the URL where the OP redirects the user. This is impractical in cases where you can't readily produce a browser window for the user, e.g. at the desktop login screen or in embedded systems.
In these cases, it would be better if there was a standard non-browser way to authenticate the user. OAuth still requires the user to approve each access token somehow, typically by browser. If you are standing at the desktop login at the only computer in a public library, and don't have a browser phone or similar, it is unlikely that you'll be able to make such an approval. Furthermore, the library computer have little use of the access token once you're done using the computer. Again, OAuth appears to me to concern authorized machine _access_ to a particular resource while I'm asking for machine _authentication_, which belongs in the realm of OpenID. -- Anders Feder <[EMAIL PROTECTED]> ons, 16 07 2008 kl. 13:26 +0800, skrev James Henstridge: > On Wed, Jul 16, 2008 at 12:38 PM, Anders Feder <[EMAIL PROTECTED]> wrote: > > tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer: > >> And of course any number of extensions could be created to obtain an > >> access token via an alternate path, after which normal OAuth can be > >> used. > > > > Sure, but isn't this equally true for OpenID? > > Most OpenID RPs maintain some kind of session for the user, but that > is not required by the spec (some require OpenID auth to perform each > action). > > In contrast, the whole point of OAuth is to generate an authorisation > token that can be used for machine access to a site multiple times in > the future. The OAuth service provider might use OpenID when deciding > whether to grant an authorisation token to a client to access the site > on behalf of a particular user if appropriate. > > James. > -- Anders Feder <[EMAIL PROTECTED]> _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
