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

Sun Feb 22 04:09:41 UTC 2009

Some folks believe that an RP should not be allowed to perform the duties of an OP, for example. That is, you cannot consume an assertion, and then be an OP yourself to further downstream spokes.

In our case, I think the most sensible contribution we could make is not only be an RP (consuming assertions from the public, as managed by the major portals), but once the user arrives and provisions an account, we should now maintain for them a vanity XRDS on a URL -- that at least delegates to the OP that just introduced them. If that OP is unwilling to trustnetwork with a site that the realtor wishes to introduce to his/her client, the XRDS allows other OPs to be added. The user can be invited to use this vanity openid, when acting in "realty mode".

Now, as an RP, I think we have added some value to the UCI-empowered user. The  value their realtor brings is in managing the trust network in the interest of their agency-clients - which can mean there is a need to add other OPs into the XRDS. If GoogleOP (say) refuses to trust network with some realty RP (because there is no commercial value to the portal or they cannot come to business/usage/licensing terms), if nothing else the realtor portal itself can act as a OP to that site --  by bridging the two trust domains. In this way, the reachability of the user is not influenced by which trust networking posture the megaOP adopts (which will typically focus on general consumer interests, rather than the more "professional-grade" issues that guide a client/agent relationship.)

Now, I can quickly see the day  when legal terms are added to assertion that prevent RPs re-purposing the data in the assertion (to limit the  captured user to the trust networking business model that funds the metaPortal). Sensible RPs will have to compartmentalize their source of attribute data from OP assertions, ensuring they can demonstrate they have captured user information without reliance on the user names/attributes that many an OP will undoubtedly make property claims over (a la facebook).

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of SitG Admin
> Sent: Saturday, February 21, 2009 4:55 PM
> To: general at openid.net
> Subject: [OpenID] Trying to understand OpenID/OAuth (hybrid)
>
> 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
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general