Trusting OpenID

We started off the morning, as is our tradition by building the schedule for the conference. Lots of good sessions proposed and many I will have to choose between. I love seeing these things come together.

I started off the morning at David Recordon and Josh Hoyt's talk on OpenID authentication in the new OpenID 2.0 spec. During a discussion of how OpenID 1.1 works, a good discussion of phishing broke out. Someone asked what's to keep a relying party from purposely misdirecting a user to a site that's spoofing the user's IdP and stealing the user's credentials. David said "Nothing."

Gasp! But actually, that's the right answer. Phishing can only be reliably stopped at the browser. Server-side band-aids exist, but this is where identity selectors like the one in CardSpace play a role. (Also watch to see if Sxipper helps here.)

OpenID is a simple authentication protocol that doesn't provide any kind of trust model. There's no built-in way to determine, for example, whether the IdP is trusted by the RP. The RP can do this out of band, of course.

Johnny Dupu from Sxip talked about OpenID Sign Assertion that allows a user to collect signed SAML assertions from 3rd parties, store them on their IdP and send them to RPs. An scrimmage erupted about broke out over who trusts who in this scenario. Is the RP trusting the IdP or is the RP trusting that the user has selected an IdP that will accurately represent her. This distinction seems to be important in context. Some use cases will want to trust the user to choose a trustworthy IdP, other RPs will be very concerned about which IdPs they trust.

This is, again, a selector (client side) problem. How can an RP indicate the kinds of IdPs that they will except?

This is made more complicated by redirection. OpenID allows users to redirect an authentication request from one site to another. This means that I can use as my OpenID even if I'm using as my OpenID IdP. Trust mechanisms need to be established between the RP and the delegate who is the true IdP.