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
