[OpenID] the OAUTH question, harmonization in OpenID forums, a little reflection on OAUTH in US realty.

[Peter Williams]

Could the OAUTH and OpenID camps start by agreeing to harmonize terms (to help the ignorant, like me)?

As far as I can tell, the "Service Provider" (SP) in the OAUTH model is known as the IDP/AA/OP in the SAML/openid model for push/pull assertion protocols.

Both seem to call the classical relying party the consumer (of the assertion/ticket), though because of the degree to which SAML use cases 99% overlap with openid, the consumer is also commonly referred to as a Service Provider.

A joint document might be written. Apart from harmonizing language, there doesn't seem to be a lot to do.

I'll hazard a guess at which why this has not already happened. Perhaps folks can correct anything too outlandish. The only claimed rationale for OAUTH existing, so far discovered, is the claim to a scope beyond which openid auth is appropriate (e.g. openid auth and YADIS are http protocols and are thus poor in a SOAP over message queuing environment --  since the architecture sorely lacks a binding model). If one accepts that, then the place in a cooperative stack alongside the openid layer could be defined, with openid merely being another particular layer -as opposed to the name the of whole. If there is an ego-war going on over this (whole vs part) and someone's legacy in the written history of the web is at stake, then there is obviously little hope of openID+ OAUTH formal harmonization.

In general

1 OAUTH seems much less pretentious in its tone, than OpenID. I see lots of denial in openid-land that it is other than just variant of stuff others have worked on for years, repackaged and tuned for the current web2.0 wave. I don't see that in the OAUTH tone. It seems quite deferential and respectful. There is no "identity is distinct from security" rubbish, seen the conference circuit spin scene.

2 Both showcase minimalism in design ethos, but again, I dont detect an edge in OAUTH. Openid comes across in its use of minimalism as almost presenting a requirement for religious devotion: it's often got an edge, warring agin the half-implied "evil other stuff". There is a notable absence of the "standing on the shoulders of giants" rhetoric. OAUTH writers on the other hand evidently had higher schooling (or perhaps it's a cultural norm of its community).

As I think now about application (and thus making a contribution worth having), the realty community's own peculiar data querying protocol is now reaching for national scale, wanting to quickly achieve coverage ofmost, authoritative properly-for sale listing data by aligning all the data owners ...via a new "higher-standard of compliance" initiative. For our little contribution as technologists, we also websso-enabled our server farm, using techniques than allow both SAML and openid endpoints. I'm now wondering if I should also add in the option of  an OAUTH endpoint, too, at least for the http binding layer (and perhaps the payload auth).

There is general consensus in US Realty that no-realty specific standardization is needed: vendors just choose one or all of openid/SAML/OAUTH/certs, and we will see if any actual profiling for interworking is required, later on. This stuff is all commodity, and there is no reason to make it a competitive issue.

Hopefully, for a newbie on OAUTH (focused on openid), this is just a re-statement of the obvious - with some early thought of how it might be applied, with little  fuss, to one data  querying web protocol. Thanks Yahoo! I'm happy to just follow the lead.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Saturday, December 13, 2008 5:34 AM
To: Allen Tom; SitG Admin; general at openid.net
Subject: Re: [OpenID] My answers to the nominee questions

Say more!  given the OP is the deliverer of "the data".

Why not use the AX extension for these querying functions, given the openid association (over which an OP knows it itself has recently sent an assertion) is essentially a persistent authorization ticket?

Do we need to reopen the backchannel flow of openid messaging to deliver AX (and the other openid extensions being normalized)?

Was the openid2 backchannel flow closed, to facilitate OAUTH getting its spot in the stack (under some Identerati deal)? Should we reopen it?

Architecturally, it seems silly to do adopt OAUTH, if openid would do the same job using a mere extension.

(Im pretty ignorant on the topic of OAUTH, but open minded.)

I keep waiting for the RDF crowd to define an openid extension that is a(nother) binding for SPARQL queries, leveraging the authorization functions of the openid association keys and assoc-identifiers to do I&A and machine authz - much as folks use SSL session-keys and session-identifiers.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Allen Tom
Sent: Friday, December 12, 2008 6:48 PM
To: SitG Admin; general at openid.net
Subject: Re: [OpenID] My answers to the nominee questions

SitG Admin wrote:

It would be nice if RP's had a "I'll scratch your back if you'll scratch mine." system by which they could send short messages to one another's networks - for instance, Monster.com would say "Hey Yahoo, please notify all the Friends of this user on your network, blah blah blah." and Yahoo could do so.

Yahoo has an OAuth protected API that allows a Yahoo user to authorize an RP to write to the user's Activity Stream using the Yahoo! Updates API. The user's connections would be able to see the message in their Updates feed. This is very similar in concept to the News Feed on other sites.

It would be really nice if a user could sign into an RP using OpenID, and simultaneously authorize that site to access their data on Yahoo using OAuth. Expect to hear more about this soon.

More info about the Yahoo! Updates API is here:
http://developer.yahoo.com/social/updates/

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081213/a0c17bfe/attachment-0002.htm>