[OpenID] Trying to understand OpenID/OAuth (hybrid)

[SitG Admin]

I understand enough to see that this is an important problem, but not 
enough to really contribute to the discussion. To test (and hopefully 
develop further) my understanding, I'll disclose the most informative 
links I've found and explain as best as I can what I've got so far; 
in case others here share my frustration, I'll disclose it on this 
list instead of asking an OAuth architect off-list.

http://www.pointy-stick.com/blog/2008/03/13/explanation-difference-between-openid-and-oauth/
http://portalzone.blogspot.com/2007/12/openid-oauth-complimentary-or-competing.html
http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing

Standard relationships on the 'net are between two parties: a user 
and a site, usually. If there were graphics here, I would be drawing 
a single line with a blob at either end of it.

OpenID involves three parties (delegation can make this more 
complicated, but I'm beginning with the simple), a user and URI/IDP 
who have an existing relationship, and another site that the user is 
asking to recognize as the URI/IDP because the URI/IDP vouches for 
this.

(I realize that this is not the traditional model of OpenID, that we 
have *users* - people - not sites, but in practice this is what we 
have: the identity is centered on a URI, and the RP is dealing with 
the user through that user's browser rather than the URI/IDP through 
the web-server there.)

OAuth involves three parties (the hybrid simplifies this, but would 
then introduce additional complications), the user, a site that has 
the user's data, and another site (presumably the RP) that the user 
wants to share *some* of their data with.

Both of these would have THREE blobs if using graphics; add unique 
icons (instead of just formless blobs) for each role, and we have 
what's beginning to look like a rudimentary molecular diagram.

OpenID starts with the user telling their URI/IDP "Give me a writ of 
authority so that I may act on your behalf." (it may even start 
before that, at the RP, who says "I don't know you, anyone can claim 
to be acting on behalf of that URI/IDP; go and fetch me a letter to 
prove that you act with their blessing."), who then carries it to the 
RP (which may confirm it by actually learning the 'unique 
handwriting' of the URI/IDP so the signature can be verified) and is 
granted access to services, or whatever the RP is offering.

OAuth starts with the user telling some site (presumably a RP) that 
they want to import data from *another* site (known as "SP" for 
Service Provider), but the RP says "I don't have the authority to 
seize their data, I'll need a permission slip from the SP site. If 
*you* can bring me such a slip, *then* we can proceed." and 
dispatches the user to the SP site, where the user has an opportunity 
to prove to the SP that *this* user has the authority to make the SP 
sign a permission slip authorizing the release of whatever data was 
requested. The user then brings this slip back to the RP, and the RP 
does appropriate things with it without bothering the user, unless 
the signature on that permission slip turns out to be a forgery (or 
for any other reason the SP rejects it).

There are *two* problems with combining OpenID and OAuth, when the OP 
is not the same as the SP: the first problem is that single-sign-on 
breaks because the user must log on to *each* SP holding data they 
want to share with another site. An obvious solution to this is 
letting some OAuth-specific site (such as the OP) act as an 
intermediary between the user and all their OAuth sites, and this 
leads straight to the *other* problem: just because Alice (the user) 
has okayed Bob (the RP) to access data from Dave (the SP), doesn't 
mean that Alice wants Carol (the OP) to have that access as well.

Venturing into complicated territory, Dave might check Alice's URI to 
see if Carol is still authorized to sign writs of authority for that 
URI (imagine that Carol used to be Alice's boss at their company, but 
then the company fired Carol - and though Carol is still Carol, she 
doesn't represent the company anymore). Alice might keep an XRDS file 
about her SP's (including Dave) at her URI, but then everyone in the 
world knows where Alice keeps her data (and what permissions she has 
given to various OP's to access that data). Anyone can tell, at a 
glance, whether Alice has any data types they would be interested in, 
and - if so - which OP's they should compromise to gain access to it. 
Encryption (using keys held only by each SP) could help in case of 
breaches, but it seems that the ready, stop-gap measure is simply to 
protect the XRDS file with another OAuth provider.

-Shade