Over the past few days at the Internet Identity Workshop 2006B, a common theme that has been discussed is trust and especially the lack thereof between a Relying Party (RP) and the OpenID Provider (OP).
Dick Hardt's position is that the trust is between the RP and the user and the user and the OP -- not between the RP and the OP. It is up to the user to pick a trustworthy OP.
The problem with this position is that it is fine for valueless transactions (like identifying a user entering a comment on a blog) but very wrong for an RP that has resources that it needs to protect. Such resources include things like bank accounts, merchandise (ecommerce), or even just data that needs privacy protections such as my contact info, or my address book, etc.
The reason why trust must exist between the RP and the OP in such cases is that the RP MUST protect the resource from a malicious user who is trying to get to some other user's data. So the RP has to do things with the OP to ensure that the OP isn't confirming an identity for another user (and therefore the RP has some level of trust that the OP is confirming identities for users in its own world).
So it's not that the RP MUST trust the OP in the case where everything is as it should be (the case where it is the right user using the right OP to get to their own data at the RP), but that the RP MUST TRUST that the OP is not enabling the malicious user.
In order to enable such trust, OpenID will end up having to replicate much of the protocol protections that currently exist within Liberty ID-FF and SAML. My opinion is, of course, that rather than replicating things yet again, profile them.
Tags : identity / trust / saml / liberty alliance / openid / security / id-ff / iiw2006b / iiw
4 comments:
It strikes me that if you don't trust the Identity Provider (OP in your terminology), that's the same as not trusting the user. The whole point of the user asserting an identity to the RP is that the user is saying "I trust this Identity Provider", to second guess the user is like those annoying password checkers that don't like my password because, although it contains interspersed alphabet characters and punctuation, it doesn't contain both an alphabet character and a number, and is therefore invalid.
As a user, I'm asserting that I trust my identity provider. As a user, I'm asserting that I trust my password. Heck, as a user I'm asserting that I trust the fact that the credit card is stored in my pocket to provide some level of physical security. Offering that the Relying Party can dictate too many terms to the Identity Provider is akin to requiring that my wallet have a lock with a seperate key on it.
The user has to trust both the RP and the OP (note that I agree the right term is IdP -- OP is the OpenID term for the IdP). You trust the RP to only give access to your resource/data at the RP to you and you trust the IdP to not assert your identity when it isn't you.
This article was driven by the fact that several people in the OpenID community were asserting that there's no need for trust between the RP and the IdP. A point that I disagree with for the reasons outlined.
Pardon my ignorance, but I don't understand your point. Care to explain? It seems you're mistaking authentication for authorization.
By asserting my OP to the RP, I assert that my OP can be trusted to identify me. Now, what "me" means is up to the OP to determine and outside the scope of OpenID.
It is outside the scope of a protocol -- neither SAML nor OpenID nor any other SSO protocol that I am aware of have this kind of trust burned into the protocol.
However, Dick (and numerous other OpenID Proponents) have repeatedly stated that there's *no* trust between the RP and the OP. The point I made in the article is that you can only do that for valueless transactions (and by valueless, I don't mean just from a $$ point of view, I also mean from a privacy and security point of view).
The RP controls a resource to which the user is given access. As that resource has more value, the need for trust in *all* the parties to the transaction increases.
Post a Comment