Discovering OpenID Relying Parties

Yesterday Paul blogged about his experience logging into Wishlistr with his Yahoo OpenID.

But, when I tried to do so, Yahoo! showed me the following warning



What would Wishlistr need to do to 'confirm its identity' to Yahoo such that users wouldn't see this (likely enthusiasm killing) warning?

I commented on Paul's blog that it might have something to do with OpenID Relying Party discovery. Section 9.2.1 of the OpenID 2 spec defines how to verify the return_to URL in an OpenID authentication.

OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party.

I tried requesting the XRDS description from Wishlistr to no avail (curl --header "Accept: application/xrds+xml" -i -v http://www.wishlistr.com ). Section 13 of the OpenID 2 spec makes it a SHOULD for relying parties to support discovery. With the adoption of OpenID 2 just beginning to ramp up, relying parties supporting discovery may be a ways away.

Please note that this is just my guess as to what might be causing the warning. There are many other possible causes as well. Though I do believe that RP discovery is a key feature of OpenID 2.

Tags: OpenID, Discovery, Relying Party

Identity API for the Internet Identity Layer

Patrick Harding has a great post today on "A Model for an Internet Identity Layer". He breaks down the Identity Layer into three sub-layers. It addition he points out that...

In addition, we have found that applications developers are spending far too much time concerning themselves with the lower levels of the identity layer. App developers need to be able to leverage a standard identity API interface that interacts with the claims sub-layer. The developer should receive all the information it needs via this API directly from the claims sub-layer. This information obviously manifests as claims and as such means that application, by default, must become claims aware. Today, this likely just means user attributes or a role value, but in the future this may include actual authorization decisions. Leveraging a standard API that allows an application to plug-and–play with the identity layer offers some future proofing as the identity protocols underneath change.

Interestingly enough, Phil Hunt talks specifically about this issue his post yesterday.

You see, the idea isn't just to support identity privacy and governance, but to create an application identity API (aka Attribute Services API) that allows applications to become decoupled these issues of having to support all the protocols and technologies out there. It lets the enterprise's decide how and when applications should access identity information and by what means.

The API the Phil references is the IGF AttrSvcs API that is part of the openLiberty project. I believe this API address a key component of the "Identity Interface" and "claims sub-layer". It's going to be very important to track policy at the "Identity Interface" and the Identity Governance Framework addresses these issues.

Trust relationships in OpenID

A while back I wrote the following to the OpenID general list serv.

As I see it there are 3 parties involved in the transaction: the user, the OP and the RP. There is some trust/risk factor associated with each relationship.

From the user's perspective they "trust" the OP (either because they want to spam and so are using an OP that makes "false assertions", or because they trust the OP to protect their authentication credentials and represent them correctly on the web). The user may or may not trust the RP, but by logging in they are making some level of trust/risk assessment.

From the OP's perspective the user represents some risk/value metric (too many "bad" users and the OP gets blacklisted). The OP protects that risk by potentially verifying email or cell number, supporting PAPE and other strong authentication methods, etc. The OP also has a risk/value metric with the RP though this is probably not super important right now. I can envision a smart OP warning me about authenticating to an RP that it some how determined is not "trustworthy".

From the RP's perspective, they have a risk/value metric on the user (e.g. Is the user going to be a good citizen of my community? Are they going to abuse the resources I provide? How much effort do I want to put into detecting "bad apples"?). The RP also has a risk/value metric on the OP (e.g. When the OP says they support the PAPE extension do they really do it?). Finally the RP has a risk/value metric on the resource/service they provide. From a business perspective I don't believe it's wise to blatantly "trust" the user if the resource/service is highly valuable (e.g. moving funds between accounts). Most users today don't have the sophistication to make good decisions.

Ok, so maybe I was a little unfair in my characterization of “most users”. I was trying to say that I don't believe many users know how to chose a good OP. In fact many will just use an OP they already have (which puts pressure on those OPs to be good citizens; that's a “good thing”). So, if an RP has a high trust metric with the user's OP, then they can more confidently trust the user as well. On the RP side its really an assessment of risk against the “User:OP“ pair.

Tags: OpenID, Trust