Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-06-03 Thread Martin Atkins
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

2007-05-28 Thread Claus Färber
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: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-18 Thread Marius Scurtescu
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

2007-05-18 Thread Josh Hoyt
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

2007-05-18 Thread Marius Scurtescu
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

2007-05-18 Thread Josh Hoyt
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: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-17 Thread Josh Hoyt
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

2007-05-17 Thread Alaric Dailey
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

2007-05-17 Thread Josh Hoyt
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