Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Noah Slater
On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
 A request for an OpenID Identifier SHALL NOT issue a 303 response.

This is even worse and also backwards incompatible. All the OpenIDs that
currently use 303 redirects, including mine, will all break.

Given two backwards incompatible changes I hardly see how one which breaks
existing OpenIDs is favourable to one which changes how some are handled.

 The change you are proposing is not backwards compatible -- an RP that's
 decided your identifier is example.com/about would then decide it's
 example.com/ as soon as it upgrades to the new version, and that
 wouldn't be good for existing users.

I think it should behove the OpenID group to actually estimate how many people
might be using 303 redirects in conjunction with an OpenID such as I am before
concluding that the change should not be made.

I have a sneaking suspicion that I may be the only person.

If that is that case, I am happy to inform you that I don't mind the change.

 The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a
 mechanism to publish discovery information at a URL which does not have
 HTML content.

Sure, but that doesn't help me and my use case.

 The code path you are are requiring the implementations to change
 (OpenID discovery and normalization) is, with the combination of
 different identifier types, protocol versions, and discovery schemes,
 already one of the most tangled chunks of code involved.  I acknowledge
 that your proposed change, in isolation, seems simple enough, but that
 code *really* doesn't need another branching condition in it.

Arguing the complexity of the implementation is just wand waving without some
concrete evidence to suggest that this would be a complex change.

Most HTTP libraries should offer simple hooks into the redirect chain.

 I appreciate the spirit of your suggestion.  It's a terrible thing to
 say oh, we follow standard X, except in the cases outlined in appendix
 B, which you will have to modify your X-implementation to be aware of.
 But, practically speaking, the use case is not compelling enough to
 overcome the cost of change.

Again, I don't think you have provided any specifics about the cost of change.

We don't know how many people use 303 redirects with OpenID and we don't know
exactly how complex a change to the OpenID libraries would be.

 And it's not like you have an RP
 implementation that *almost* works except not quite because the
 libhttp-follow-redirects-
 and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case-
 return-the-intermediate-url function in your web framework is returning
 something incompatible with OpenID.  (Or, if it is, I really want to
 hear about what HTTP client implementation you're using.)

Well, many HTTP clients provide clear hooks into redirect chain.

 I know that *you* think the semantics are clear, but the fact that
 knowledgeable people have been haggling over it for weeks on the list
 suggests that it may not be.

Well, from my perspective it seems like eventually most people on the list
agreed that it was an issue as outlined by my use case. In any case, the
simplest things are often discussed at great length, if for not other reason
than the colour of the bikeshed, so this is a non sequitur.

 So, IMHO, the best way to make this problem go away is to just say that
 303s are an invalid way of telling an RP where discovery information is.

As I mentioned above, instead of altering how all the existing 303d OpenIDs
(again, perhaps I am the only one using OpenID like this) are handled, you would
break them all, permanently.

 RPs will continue to work the way they do now, for backwards-compatibility
 purposes

How are you so sure? Perhaps they will just stop working one day.

 and anyone publishing OpenID identifiers in the future will be able to find a
 clear statement about it in the spec.

This makes no sense. The current specification clearly tells me why my 303
redirect doesn't work, but that offers no comfort for me in the same way as
future explanation explaining why my 303 no longer works will also offer no
comfort.

Thanks,

--
Noah Slater http://bytesexual.org/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread James Henstridge
On 19/03/2008, Noah Slater [EMAIL PROTECTED] wrote:
 On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
   A request for an OpenID Identifier SHALL NOT issue a 303 response.


 This is even worse and also backwards incompatible. All the OpenIDs that
  currently use 303 redirects, including mine, will all break.

  Given two backwards incompatible changes I hardly see how one which breaks
  existing OpenIDs is favourable to one which changes how some are handled.

That seems to be an argument for making no changes.


   The change you are proposing is not backwards compatible -- an RP that's
   decided your identifier is example.com/about would then decide it's
   example.com/ as soon as it upgrades to the new version, and that
   wouldn't be good for existing users.


 I think it should behove the OpenID group to actually estimate how many people
  might be using 303 redirects in conjunction with an OpenID such as I am 
 before
  concluding that the change should not be made.

  I have a sneaking suspicion that I may be the only person.

  If that is that case, I am happy to inform you that I don't mind the change.

You're okay with sites interpreting your ID differently depending on
the version of OpenID they support?  Aren't you concerned that you'll
lose access to your accounts on various RPs if your OP or the RP
upgrades?  Or do you planning to only talk to RPs that support the new
version?

I also don't think that such a decision should be based on your
assertion that you're the only one who would be affected.


   The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a
   mechanism to publish discovery information at a URL which does not have
   HTML content.


 Sure, but that doesn't help me and my use case.


   The code path you are are requiring the implementations to change
   (OpenID discovery and normalization) is, with the combination of
   different identifier types, protocol versions, and discovery schemes,
   already one of the most tangled chunks of code involved.  I acknowledge
   that your proposed change, in isolation, seems simple enough, but that
   code *really* doesn't need another branching condition in it.


 Arguing the complexity of the implementation is just wand waving without some
  concrete evidence to suggest that this would be a complex change.

  Most HTTP libraries should offer simple hooks into the redirect chain.

To maintain compatibility with existing versions of OpenID, RPs would
need to perform discovery, and then decide which of two identity URLs
to use based on which protocol version is negotiated.

Whatever you might say about the existing discovery mechanism, this
does seem a lot more complex, since it intermingles discovery with
protocol version negotiation.


   I appreciate the spirit of your suggestion.  It's a terrible thing to
   say oh, we follow standard X, except in the cases outlined in appendix
   B, which you will have to modify your X-implementation to be aware of.
   But, practically speaking, the use case is not compelling enough to
   overcome the cost of change.


 Again, I don't think you have provided any specifics about the cost of change.

  We don't know how many people use 303 redirects with OpenID and we don't know
  exactly how complex a change to the OpenID libraries would be.


   And it's not like you have an RP
   implementation that *almost* works except not quite because the
   libhttp-follow-redirects-
   
 and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case-
   return-the-intermediate-url function in your web framework is returning
   something incompatible with OpenID.  (Or, if it is, I really want to
   hear about what HTTP client implementation you're using.)


 Well, many HTTP clients provide clear hooks into redirect chain.


   I know that *you* think the semantics are clear, but the fact that
   knowledgeable people have been haggling over it for weeks on the list
   suggests that it may not be.


 Well, from my perspective it seems like eventually most people on the list
  agreed that it was an issue as outlined by my use case. In any case, the
  simplest things are often discussed at great length, if for not other reason
  than the colour of the bikeshed, so this is a non sequitur.


   So, IMHO, the best way to make this problem go away is to just say that
   303s are an invalid way of telling an RP where discovery information is.


 As I mentioned above, instead of altering how all the existing 303d OpenIDs
  (again, perhaps I am the only one using OpenID like this) are handled, you 
 would
  break them all, permanently.


   RPs will continue to work the way they do now, for backwards-compatibility
   purposes


 How are you so sure? Perhaps they will just stop working one day.


   and anyone publishing OpenID identifiers in the future will be able to 
 find a
   clear statement about it in the spec.


 This makes no sense. The current specification 

Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Noah Slater
On Wed, Mar 19, 2008 at 08:43:46PM +0900, James Henstridge wrote:
   Given two backwards incompatible changes I hardly see how one which breaks
   existing OpenIDs is favourable to one which changes how some are handled.

 That seems to be an argument for making no changes.

No, it's an argument to make the backwards incompatible change that effects
people in the smallest possible negative way. Your suggestion replaces one
non-compliant usage of HTTP with another, which is hardly a step forward.

 You're okay with sites interpreting your ID differently depending on
 the version of OpenID they support?  Aren't you concerned that you'll
 lose access to your accounts on various RPs if your OP or the RP
 upgrades?  Or do you planning to only talk to RPs that support the new
 version?

They already do this.

cf. http://chatlogs.planetrdf.com/swig/2008-03-10.html#T16-58-17

 I also don't think that such a decision should be based on your assertion that
 you're the only one who would be affected.

I wasn't really making an assertion, more a jocular suggestion that this is
probably not very widespread, so it would be nice to fix it now while we can.

 To maintain compatibility with existing versions of OpenID, RPs would
 need to perform discovery, and then decide which of two identity URLs
 to use based on which protocol version is negotiated.

Again, strictly this is true, but given the woeful implementations we have at
the moment (see above reference) I really can't see that this would happen.

 Whatever you might say about the existing discovery mechanism, this
 does seem a lot more complex, since it intermingles discovery with
 protocol version negotiation.

Sure, it might be a bit more complex, but that is not an objective technical
argument for ignoring the low level HTTP semantics.

 Perhaps it'd help if you described exactly what your use case is.

cf. http://openid.net/pipermail/general/2008-March/004362.html

 If you want to have an identity URL which is used as is by OpenID RPs
 doing discovery but have web browsers redirected to another URL, have
 you considered using meta http-equiv=Refresh ... instead of a 303
 redirect?  This should have the desired effect with OpenID 1, 2 and
 any future versions.

I am using 303 redirects for the explicit semantics this affords under the TAG's
httpRange-24 resolution, and so a http-equiv meta element would not work.

cf. Dereferencing HTTP URIs, 4.1 Using HTTP to Represent Associations
http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14.html

Thanks,

--
Noah Slater http://bytesexual.org/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Johnny Bufu

On 19-Mar-08, at 2:51 AM, Noah Slater wrote:

 On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
 A request for an OpenID Identifier SHALL NOT issue a 303 response.

 This is even worse and also backwards incompatible. All the OpenIDs  
 that
 currently use 303 redirects, including mine, will all break.

By all standing definitions (both v1.x and v2.0), your http:// 
bytesexual.org/ URL is *NOT* an OpenID. You are the only one calling  
and expecting it to be, based on your interpretation and proposed  
changes.

 Well, from my perspective it seems like eventually most people on  
 the list
  agreed that it was an issue as outlined by my use case. In any  
 case, the
  simplest things are often discussed at great length, if for not  
 other reason
  than the colour of the bikeshed, so this is a non sequitur.

Note that there have been objections to your proposal, which have not  
been answered. This effectively accounts to a veto for the proposed  
changes getting accepted.

 On 19-Mar-08, at 7:54 AM, James Henstridge wrote:
 On 19/03/2008, Noah Slater [EMAIL PROTECTED] wrote:
 That seems to be an argument for making no changes.

 No, it's an argument to make the backwards incompatible change  
 that effects
  people in the smallest possible negative way. Your suggestion  
 replaces one
  non-compliant usage of HTTP with another, which is hardly a  
 step forward.

Per the above, the case of making no changes at all still stands.


Johnny


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Kevin Turner
On Wed, 2008-03-19 at 23:54 +0900, James Henstridge wrote:
 The fact that some sites incorrectly resolved the redirect to
 /about/ is probably due to the non-standard response headers for
 http://bytesexual.org/ -- it contains a relative URI reference in the
 location header, while the spec requires an absolute URI.
 
 Do you have more information about which sites exhibit which
 behaviour?  Or better yet, which libraries they are using?

The current behaviour of all openidenabled.com libraries would be to
either

a) fail, due to the relative Location header (this may depend on what
http client backend is used), or 

b) normalize that as http://bytesexual.org/about/

given Johnny's earlier comments, I expect that openid4java behaves the
same way, and I'd expect the same from the -- well, I was going to say
early Perl implementations, but really, I can't think of an
implementation that I *wouldn't* expect that behaviour from.  (Unless
perhaps Noah or Sam Ruby have written their own implementations.)

And my hunch is that the implementation which resolved it as
bytesexual.org did so not because it was honoring 303 vs 302 semantics,
but because it wasn't properly normalizing with redirects at all. (I'd
happy to be shown wrong on that count.)


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Web Services

2008-03-19 Thread McGovern, James F (HTSC, IT)
 Out on the Wiki is a discussion on creating a WS-Security profile to
support OpenID. Is anyone planning on taking this further?


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Manger, James H
As confusing as HTTP redirect semantics might be, I am confident that
you will not find anyone that deliberately chooses to return a 303 See Other
without explicitly wanting to keep the original URL as the identity and
the new URL as merely a (stable, cachable) location for the current response
(eg current OP details). I am confident this will be true for any web
content, not just OpenID.

[Aside: Browsers displaying the new URL in the address bar after a
303 See Other is not a counter-example. The new URL is the address of the
displayed response. It is NOT the address that will be reused if the
original request (eg an HTML form submission) is retried.]

The ability to serve discovery details from a location that is different
from the claimed_id is desired functionality:
1* You can achieve it using X-XRDS-Location (HTTP header or meta element),
but only if you deliver other content (eg HTML) at the claimed_id;
2* You can achieve it using an i-name (by the abstract nature of those ids
and the various synonyms explicitly defined for those ids);
3* You can achieve it via directed identity if your OP cooperates,
and with a very extra request/response pairs;
4* You CANNOT achieve it using standard HTTP (with 303 See Other).

The question is whether OpenID wants to bother supporting #4.

In adding support for XRI/XRDS/i-names OpenID 2.0 made HTTP URIs
somewhat second-class citizens by offering some functionality only
when XRI/XRDS is used, even when sensible HTTP mechanisms
were also available. Two examples are: supporting X-XRDS-Location but not
303 See Other; and indicating an OP Identifier with a special XRDS Type,
but not with a special openid2.identifier value.

For a true-believer in i-names, not offering an HTTP-way for some
functionality is not important (perhaps even helpful for promoting i-names).
For a true-believer in HTTP (less enthused by i-names), the lack of an
HTTP-way is a problem.

Kevin Turner said:
Amend the specification to say:
A request for an OpenID Identifier SHALL NOT issue a 303 response.

Thankyou Kevin, for a lateral solution.
It is not the fix I want (proper HTTP-style support for 303 See Other),
but at least it explicitly tells people that OpenID 2 does not support
303 semantics. That should allow proper 303 support to be added later
without big backward compatibility issues.

[Aside: In practice, OpenID RP libraries would probably not be changed
to explicitly reject 303s -- particularly as your major argument is that
that sort of change makes the code too complex. Rejecting or interpreting
303s both require explicitly handling redirect codes, as opposed to setting
the follow redirects automatically option of the HTTP client library.]

Objections to proper support for 303s don't say the proposal is wrong.
They just imply it is not worth the effort: code too complex, do not have
to obey HTTP, work arounds available, 2.0 is finished.
Not surprisingly, these judgements are not convincing to some
HTTP true-believers.


Perhaps I will add a note to the OpenID 2.0 errata page stating
HTTP 303 See Other semantics are not currently supported so they should
be avoided when hosting OpenIDs.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Johnny Bufu

On 19-Mar-08, at 6:42 PM, Manger, James H wrote:

 [Aside: Browsers displaying the new URL in the address bar after a
 303 See Other is not a counter-example.

Yes, it is.

 The new URL is the address of the displayed response.

The new claimed_id URL is the address of the discovered information  
(which is of interest to the RPs in this case).

 It is NOT the address that will be reused if the
 original request (eg an HTML form submission) is retried.]

How is this relevant?  If the OpenID login form is re-submitted, the  
User-supplied ID will be the first resource, but what difference does  
this make?


Johnny

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs