Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
Claus Färber wrote: Marius Scurtescu schrieb: The new attribute values are needed in order to signal an OpenID 2 provider. Why is this necessary? Is OpenID 2 incompatible? In other words, what happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x Provider? If the OpenID 1.x Provider just ignores additional message fields (i.e. treats them like an unknown extension), then no new rel values are needed. If this is not the case, maybe the OID 2 spec can be changed to make it possible. One incompatibility that springs to mind is that it is permissable to talk to a 2.0 OP via a POST request with the arguments in the entity body, while a 1.1 will likely barf on this since 1.1 only allowed for GET requests with the arguments in the query string. A 2.0 RP that uses a GET request and uses extension prefixes that match the ad-hoc field names used for the 1.1 extensions could, in theory, talk to a 1.1 OP without any problems. That is, unless I've missed something. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
Marius Scurtescu schrieb: The new attribute values are needed in order to signal an OpenID 2 provider. Why is this necessary? Is OpenID 2 incompatible? In other words, what happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x Provider? If the OpenID 1.x Provider just ignores additional message fields (i.e. treats them like an unknown extension), then no new rel values are needed. If this is not the case, maybe the OID 2 spec can be changed to make it possible. It is always better to detect features, not versions. Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
+1 for leaving our XRI and Yadis. Claus Färber wrote: Josh Hoyt schrieb: On 5/17/07, Dmitry Shechtman [EMAIL PROTECTED] wrote: There has been a simplification suggestion floating around since long ago: resolve i-names via http[s]://xri.net/. -1. If XRI is to be included, it should be done the way that it's intended. One possible solution that would address this problem as well as the unfinished XRI specification is to split out Yadis and XRI discovery out from the OpenID Authentication spec and into separate documents. That way, they could wait until the XRI specs are done and the OpenID spec will be shorter and easier to understand. +1 for leaving out XRI XRI adds too much complexity without any real benefit. Well, i-numbers _do_ provide persistence, which is something OpenID does not have. However, Relying Parties can't rely on it as most users will use HTTP-based OpenID identifiers. If persistence is a concern (and it may be for some Relying Parties), then there should be an OpenID extension for it and implementers should only have to implement said extension. Further, XRI-based OpenID identifiers only provide persistence by giving up one of the goals of OpenID: decentrality. (An OpenID extension could provide persistence and yet retain decentrality by using the public keys for asymmetric encryption as a persistent or semi-persistent token.) Of course, there's no reason why http://xri.net/=foo could not be a OpenID URI just like any other HTTP URI. But the complexity of having XRI-based identifiers used with OpenID should reside with the folks who run the XRI gateway (one software product), not those who implement Relying Parties (several software products). Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
As a relative newcomer to the OpenID community, I realize this may have been debated endlessly already, and I may just be shouted down. It definitely has been debated endlessly. Or am I alone here? No, you aren't. There are many who agree with this entirely, some of whom have expressed their opinion on the various OpenID lists, but at no avail. My suggestion at this point would be to simply denounce OpenID 2.0. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: 7.3.3. HTML-Based Discovery A LINK tag MUST be included with attributes rel set to openid2.provider and href set to an OP Endpoint URL A LINK tag MAY be included with attributes rel set to openid2.local_id and href set to the end user's OP-Local Identifier Could somebody please enlighten me as to what's wrong with leaving those as openid.server and openid.delegate respectfully (i.e. backward-compatible)? The new attribute values are needed in order to signal an OpenID 2 provider. But you bring up a good point, backwards compatibility can be easily broken here. In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Probably the spec should say this in section 7.3.3 and give clear instructions regarding OpenID 1.1 tags. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote: On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Also note that it's allowed to put both values in the rel attribute of one tag [1], which eliminates a little bit of bloat. Josh 1. http://www.w3.org/TR/html401/struct/links.html#adef-rel ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 11:45 AM, Josh Hoyt wrote: On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote: On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Also note that it's allowed to put both values in the rel attribute of one tag [1], which eliminates a little bit of bloat. Good point. I'm sure that this will break a few implementations, checking openid4java right now... Thanks, Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Dmitry Shechtman [EMAIL PROTECTED] wrote: I'm sure that this will break a few implementations It certainly will break PHP-OpenID. Which implementation are you referring to as PHP-OpenID? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
I think this argument is bogus. There is hardly any additional complexity aside from XRI and Yadis. I'm willing to entertain suggestions for simplifying the handling of those discovery mechanisms. The specification is significantly *longer*, but that's primarily because it's much more rigorously specified. If you want it simplified, don't just talk abstractly about complexity, make suggestions about how to simplify it. aside from XRI and Yadis? XRI alone is twice as complex as OpenID 1.1! There has been a simplification suggestion floating around since long ago: resolve i-names via http[s]://xri.net/. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
There is a proposed solution that we had consensus on (Dick's fragment proposal.) Would you please specify whom you are referring to by we? I understand that various matters are being discussed outside of this list, but shouldn't the whole community be part of the decisions made? I didn't hear a single reservation regarding my Canonical ID proposal (apart from But emails also get recycled!). Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: 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. There are valid use cases for both of these features, but I think that they can be addressed in a future release of OpenID. I want to get the features that are already implemented out to users. Part of what will be nice about getting 2.0 out is that it will give us more freedom to start playing with new ideas. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Final outstanding issues with the OpenID 2.0 Authenticationspecification
I hate to be a PITA but these issues were brought up a while ago by Eddy Nigg and Myself. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 17, 2007 15:50 To: Alaric Dailey Cc: OpenID specs list Subject: Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: 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. There are valid use cases for both of these features, but I think that they can be addressed in a future release of OpenID. I want to get the features that are already implemented out to users. Part of what will be nice about getting 2.0 out is that it will give us more freedom to start playing with new ideas. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: I hate to be a PITA but these issues were brought up a while ago by Eddy Nigg and Myself. I understand, but at that time, as now, I was trying to get the spec to be finished. We've been in something of an informal feature-freeze for a while. Perhaps we should have explicit feature-freezes. I'd suggest starting an OpenID 3 thread to talk about the features that you want to add. That way, you can start trying to convince people that your features should go in without having to battle with people like me who just want to have a stable spec release with the improvements that we already have. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
