RE: Non-interactive logins

2008-07-17 Thread Anders Feder
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

2008-07-16 Thread Anders Feder
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

2008-07-16 Thread Nat Sakimura
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

2008-07-15 Thread Anders Feder
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

2008-07-15 Thread 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

2008-07-15 Thread Anders Feder
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

2008-07-15 Thread John Panzer

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

2008-07-15 Thread Anders Feder
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

2008-07-15 Thread 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


Re: Non-interactive logins

2008-07-15 Thread 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.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs