RE: Non-interactive logins
This looks like an interesting proposal. A 'black box' with regards to how the application obtains assoc_handle and signature from the OP remains, but it looks like a step in the right direction. What remains to be done to elevate this proposal this to standard? ons, 16 07 2008 kl. 15:09 +1000, skrev Manger, James H: Hi Anders, There has been some work on this important issue, though it seems to have been dormant for a while. There seem to be two proposals (by Martin Atkins) using OpenID as an HTTP authentication mechanism. It is suitable for non-browser, non-interactive use cases. http://wiki.openid.net/OpenIDHTTPAuth http://wiki.openid.net/OpenID_HTTP_Authentication I really like the idea of this basic flow: 1. RP indicates it supports OpenID with WWW-Authenticate: OpenID header; 2. App interacts with the app's OP; 2. App sends OpenID authentication response to RP in Authorization header; 3. RP performs discovery; 4. RP does direct verification with OP. App --GET xxx-- RP --401 WWW-Authenticate: OpenID realm=...-- App OP [if necessary] App --GET xxx Authorization: OpenID opened-auth-request-stuff-- RP RP --GET claimed_id-- --discovery XRDS/HTML-- RP --POST ...openid.mode=check_authentication-- OP --is_valid=true-- App --200 content-- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
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
Re: Non-interactive logins
The implementation we have done at JAL is composed of the following: 1) Normal OpenID Auth 2.0 procedure 2) Extention to hook contract negotiation upon OpenID Auth 2.0 procedure 3) Actual Contract and back channel data transfer protocol negotiation. 4) Actual data transfer. For 2) and 3) above, the service provider issues a signed contract proposal, and the end user is shown the terms and conditions. If end user agrees to it or part of it, the term is finalized and counter signed, and its URL is sent back with OpenID authentication response. This contract gives non-repudiation to the parties. There after, the service provider can use the contract to retrive the desired data as par specified in the contract. The data transfer protocol can be anything. It can be OAuth, ID-WSF or something else, which should be specified in the contract. (Does not have to be: if the data acqusition URL can expose XRDS and publicise the available data transfer protocols, it can be done dynamically.) It was first reviewd at iiw2007b and the basic flow has been on the OpenID wiki for sometime: http://wiki.openid.net/Trusted_Data_Exchange , though it is a bit out of date. Also, the name Trusted Data Exchange, but the name is not quite depictive, so, it probably should be decomposed into Contract Negotiation, and something else. Note that this system has been live since the end of May this year, in the real transaction of monetary value. I do plan to propose it as the WG in the coming weeks. If you would like to join in the boat, you are more than welcome :-) =nat Anders Feder 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? If that is the case, I would like to ask the list if anybody is interested in working towards such an extension. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. XDI.ORG Vice Chair ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Non-interactive logins
Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
If I'm not mistaken, OAuth requires the user to approve the authentication request in her browser, which is an interactive action. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
Anders Feder wrote: If I'm not mistaken, OAuth requires the user to approve the authentication request in her browser, which is an interactive action. This is true, but this only needs to be done when obtaining an access token, which can be used potentially forever without further interaction from the user. 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. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
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? If that is the case, I would like to ask the list if anybody is interested in working towards such an extension. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Non-interactive logins
Hi Anders, There has been some work on this important issue, though it seems to have been dormant for a while. There seem to be two proposals (by Martin Atkins) using OpenID as an HTTP authentication mechanism. It is suitable for non-browser, non-interactive use cases. http://wiki.openid.net/OpenIDHTTPAuth http://wiki.openid.net/OpenID_HTTP_Authentication I really like the idea of this basic flow: 1. RP indicates it supports OpenID with WWW-Authenticate: OpenID header; 2. App interacts with the app's OP; 2. App sends OpenID authentication response to RP in Authorization header; 3. RP performs discovery; 4. RP does direct verification with OP. App --GET xxx-- RP --401 WWW-Authenticate: OpenID realm=...-- App OP [if necessary] App --GET xxx Authorization: OpenID opened-auth-request-stuff-- RP RP --GET claimed_id-- --discovery XRDS/HTML-- RP --POST ...openid.mode=check_authentication-- OP --is_valid=true-- App --200 content-- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs