[OpenID] Flickr / Yahoo OpenID implementation

[Peter Williams]

One can build various control layers on top of RP affiliations (a la SAML), with private local name bindings (a la SDSI).

For example:

Let the #fragment attached to the pseudonym URL be a URl-encoded, base64-encoded public key. An AC can now sign its access requests to the SP, expecting the SP to have the verification key for the signature block. The pseudonym URL indicated in OAUTH consumer key identifies the public key to use (of many that the affiliation group may hold for a given user, per SP transaction set).

One could let the PAPE value that any Sp must cite to obtain the common pseudonym (plus public key fragment) be a signed(string), where string = concat(AC realm, SP realm).that is, the ability to claim access to the pseudonym is gated  on the SP having from the AC a capability (the signed namespace->namespace mapping) that tells the OP that the SP is a member of the AC’s (consumer) trust network. The OP can have privileged access to the public key of the AC stored in an AX record, treating the AC as an openid subscriber in its own right (thanks Pat, for the idea!)

One can also play with shamir key splitting , so n of m components must be applied (by an SP and an OP) before the AC will be able to confirm the user has authorized the release of a particular photo set (executed  a particular SPARQL query…).Even more fun: play with RSA in similar vein.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Monday, January 12, 2009 11:21 PM
To: Eddy Nigg (StartCom Ltd.)
Cc: general at openid.net
Subject: Re: [OpenID] Flickr / Yahoo OpenID implementation

And is it true that if the user delegates to an OP identifier (only) inducing directed id flow, that the user will be logged in to the RP as the finalized openid (rather than the user supplied id), even though the OP made an assertion about a Yahoo pseudonym?

If an RP now send a unique PAPE value that controls the value of the pseudonym, and an OP uses the same pseudonym for any RP citing that same PAPE request value, each RP with knowledge of the pape seed value will (a) have a common key for the user per pape value (the pseudonym),(b) a per RP persistent mapping between the finalized URL -> pseudonym.

In an OAUTH environment, a user can now release to the AC knowledge of the finalized URL that the SP has bound to the very same pseudonym to which the AC has bound its own finalized URL. They can now engage in peer entity authentication without the OP. Release of the local name binding at the SP to the AC is a user act of approval to pull the users data, using the pseudonym as the consumer key and the SP-local finalizedURL as the consumer secret.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Monday, January 12, 2009 11:07 PM
To: Eran Hammer-Lahav
Cc: general at openid.net
Subject: Re: [OpenID] Flickr / Yahoo OpenID implementation


On 01/13/2009 08:40 AM, Eran Hammer-Lahav:

OpenID is a little/vary/completely broken when it comes to its handling of Claimed Identifiers. The level of how broken depends on your use case and threat model. It is also inconsistent in that if you use your blog URL (custom domain name) as an OpenID, but the hosting service you use redirects to another domain (for example, you use http://example.com as your blog, but your service is serving it off http://example.blogservice.com or http://blogservice.com/example), the RP has to use the redirected URL and not the one you entered.

Correct! And this is by design, it's not broken. And don't even think about changing this pattern :-)
Regards



Signer:

Eddy Nigg, StartCom Ltd.<http://www.startcom.org>

Jabber:

startcom at startcom.org<xmpp:startcom at startcom.org>

Blog:

Join the Revolution!<http://blog.startcom.org>

Phone:

+1.213.341.0390




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