There are 2 issues that I would like to see addressed. 1. Forcing Encryption, to protect users data en-route. 2. Validated assertions, validating certain bits of data with a third party.
I know both of these have come up before, but have met with resistence, I would submit that with Sun and AOL supporting OpenID that these issues become more important, especially protecting the users data. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 17, 2007 11:26 To: OpenID specs list Subject: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification OpenID 2.0 has been a work in progress for a long time. The specification has been largely at a stand-still for long enough for people to implement it, and even deploy it. At the Internet Identity Workshop for the past few days, I've been talking to the people from the OpenID community about what is getting in the way of calling the spec final. I'm sending this message to summarize what I've heard, get comments from those of you who aren't here at this conference, and hopefully establish a concrete plan of action that will get the spec finalized. In the conversations that I've had, there are four issues that are holding up people's approval of the specification. These issues are not new, but I'm going to list them here: 1. Identifier recycling. There are two different use cases for identifier recycling. The first, and the one that most people who I have talked to really want to solve is that of a large provider that wants to allow re-use of parts of its namespace. The second is if a user wants to relinquish control of an identifier without relinquishing control of the places that they have used this identifier. A concrete example of this is if I ever choose to stop paying for j3h.us. 2. Realm spoofing. This encompasses the attacks that Allen Tom has described (using redirectors, proxies or XSS attacks) that create new phishing opportunities and make certain types of phishing even worse. 3. Associations in the clear. While the OpenID 2 specification specifically allows a provider to refuse to perform associations in the clear (no Diffie-Hellman or SSL), there is consensus that the specification should disallow these associations. This one's easy. 4. Reference to unfinished XRI specification. For resolving XRI and the protocol formerly known as Yadis (XRDS discovery for URLs), we're referring to a working draft specification. We can't leave the final spec referring to the draft. If these four issues are resolved, can we call the OpenID 2.0 Authentication specification done? Speak up if you have any other show-stoppers. Josh _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
