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.

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
  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
 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.

specs mailing list

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 
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: , though it is a bit out of 

Also, the name Trusted Data Exchange, but the name is not quite
depictive, so, it probably should be decomposed into Contract 
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 :-)


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

 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

 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

 - Scott

 On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote:


 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)?


 specs mailing list

 specs mailing list


 specs mailing list

Nat Sakimura (=nat)
Nomura Research Institute, Ltd. 
XDI.ORG Vice Chair

specs mailing list