Sun announced (or at least Tim did) that Sun's supporting OpenID at openid.sun.com. Sun has taken the additional step of stating that only Sun employees will have IDs there. So, if someone presents an OpenID with a base domain of openid.sun.com, you can be assured that Sun is vouching that they are an employee of Sun.
The biggest problem with this set up, of course, is that the attributes of an identifier ought to be transfered orthogonally to the identifier itself. The fact that the URL has a certain form should encode data like whether someone's an employee or not. What if Sun decides to open it up to everyone next year and in the meantime, systems have been deployed assuming that only Sun employees are entitled to these identifiers?
Still, I like that Sun's taking OpenID seriously. Ignore the employee status as URL issue and just concentrate on the asserted strength of the authentication process, if you like. Even so, there are still some flies in the ointment.
- First, how do we know this is true, except that Tim says it?
- More importantly, how does a machine know it's true?
- How do we avoid huge whitelists of machines who's OpenIDs we trust (or blacklists of machines we don't)?
The first problem is that there's no metadata exchange for OpenID that can point to machine readable policies. Brad Fitzpatrick probably wants to shoot me right now, but I think it's a problem. OpenID 2.0 will help with some of this, but I don't think it's the whole solution. I'm sure there's something from XDI we could steal, couldn't we Andy?
The second problem is that there's no reliable way to get the reputation of an OpenID or the provider. It's possible you could get away without a significant metadata exchange protocol if you had a reputation system for OpenIDs. My students and I worked on one this winter. We haven't written it up yet, but will be demoing it at IIW next week.
Update: Drummond Reed, Paul Madsen, and Eve Maler weigh in on this issue:
