Re: Problems with OpenID and TAG httpRange-14

2008-03-21 Thread Will Norris
Sorry to jump in here a little late, but I feel there are a couple of  
important points that haven't been mentioned...

On Mar 18, 2008, at 7:54 PM, Kevin Turner wrote:

 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.

You seem to have the tail wagging the dog here, and I'm a bit  
surprised no-one has called you on it yet.  Regardless of what  
specific spec addition we're talking about, I don't think the  
technical difficulty to implement it should ever be a determining  
factor in weighing the merit of the proposal.  If a particular library  
chooses not a support a specific portion of the spec based on  
technical programming factors, that is one thing.  But using that as a  
factor in deciding whether or not to accept that proposal is  
approaching very dangerous waters.

Now, regarding the specific proposal in question, I'm actually a bit  
discouraged by the arguments being made.  I see OpenID discovery  
(Yadis) and web browsers as two different applications, both of which  
happen to make use of HTTP has their transport layer.  At the most  
basic level, the application of a web browser is the retrieval of a  
document and displaying it to a user.  In addition to HTTP, this  
application could use as its transport layer FTP, Gopher, or probably  
a number of other protocols I'm not thinking of.  Yadis is a discovery  
service used to enable OpenID authentication (among other uses), but  
with no requirement to ever display the data to the end user.

When determining how one should interpret a technical spec or  
implement a particular feature, it is perfectly acceptable and  
encouraged to consider other similar implementations.  These other  
implementations should be used as supplementary guidance, particularly  
when the specification isn't clear.  However, RFC2616 is pretty clear  
in how 303 responses should be handled, namely that the new URI is  
not a substitute reference for the originally requested resource.   
For the purpose of obtaining a representation of the resource the  
redirect needs to be resolved, but only for that purpose... the spec  
is clear that these are still entirely distinct resources.

Based solely from the perspective of implementing the HTTP spec as  
written I am in complete agreement with Noah... his argument is  
entirely valid and supported by the spec.  If the OpenID spec chooses  
not to implement that part of HTTP, that is a completely valid route  
to take, but it ought to be explicit.  I'm not sure that I've actually  
heard a really compelling argument against implement 303 responses as  
Noah has described, but I'm not sure that one isn't still out there,  
yet to be mentioned.  Does this have any ramifications on the OpenID  
trust model regarding identifiers?  I don't think it does, just trying  
to think through everything.

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


Re: Problems with OpenID and TAG httpRange-14

2008-03-21 Thread Will Norris
hmm... seems I missed the entire thread over on openid-general.   
Accept my apologies if I simply repeated content from that discussion  
and for potentially adding more white noise.  Now I'm going to go read  
that whole thread to see if the above apology is necessary. :)

-will

On Mar 21, 2008, at 9:38 AM, Will Norris wrote:
 Sorry to jump in here a little late, but I feel there are a couple of
 important points that haven't been mentioned...

 On Mar 18, 2008, at 7:54 PM, Kevin Turner wrote:

 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.

 You seem to have the tail wagging the dog here, and I'm a bit
 surprised no-one has called you on it yet.  Regardless of what
 specific spec addition we're talking about, I don't think the
 technical difficulty to implement it should ever be a determining
 factor in weighing the merit of the proposal.  If a particular library
 chooses not a support a specific portion of the spec based on
 technical programming factors, that is one thing.  But using that as a
 factor in deciding whether or not to accept that proposal is
 approaching very dangerous waters.

 Now, regarding the specific proposal in question, I'm actually a bit
 discouraged by the arguments being made.  I see OpenID discovery
 (Yadis) and web browsers as two different applications, both of which
 happen to make use of HTTP has their transport layer.  At the most
 basic level, the application of a web browser is the retrieval of a
 document and displaying it to a user.  In addition to HTTP, this
 application could use as its transport layer FTP, Gopher, or probably
 a number of other protocols I'm not thinking of.  Yadis is a discovery
 service used to enable OpenID authentication (among other uses), but
 with no requirement to ever display the data to the end user.

 When determining how one should interpret a technical spec or
 implement a particular feature, it is perfectly acceptable and
 encouraged to consider other similar implementations.  These other
 implementations should be used as supplementary guidance, particularly
 when the specification isn't clear.  However, RFC2616 is pretty clear
 in how 303 responses should be handled, namely that the new URI is
 not a substitute reference for the originally requested resource.
 For the purpose of obtaining a representation of the resource the
 redirect needs to be resolved, but only for that purpose... the spec
 is clear that these are still entirely distinct resources.

 Based solely from the perspective of implementing the HTTP spec as
 written I am in complete agreement with Noah... his argument is
 entirely valid and supported by the spec.  If the OpenID spec chooses
 not to implement that part of HTTP, that is a completely valid route
 to take, but it ought to be explicit.  I'm not sure that I've actually
 heard a really compelling argument against implement 303 responses as
 Noah has described, but I'm not sure that one isn't still out there,
 yet to be mentioned.  Does this have any ramifications on the OpenID
 trust model regarding identifiers?  I don't think it does, just trying
 to think through everything.

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

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


specs and implementations (Re: Problems with OpenID and TAG httpRange-14)

2008-03-21 Thread Kevin Turner
On Fri, 2008-03-21 at 09:38 -0700, Will Norris wrote:
 Regardless of what specific spec addition we're talking about, I don't
 think the technical difficulty to implement it should ever be a
 determining factor in weighing the merit of the proposal.

I disagree here.  We don't write specs just so people can appreciate the
abstract beauty of the models we describe.  We write specs so we can
have working code solving problems.  No specification should be
considered complete without at least one reference implementation, and
the complexity of implementation should be taken as feedback to the
developing specification.

The more complexity is required, the more expensive it is to implement
and test the specification, which directly impacts adoption.  And the
more error-prone the implementations will be, hampering
interoperability.

I think this idea is fairly central to OpenID.  As others have pointed
out time and time again, there are other systems that have pretty much
all the same properties as OpenID does, they may cover them in a more
rigorous fashion, they may have been around for years or decades, but
they don't have the appeal that OpenID does today.  I believe that is
because they were perceived as too inaccessible, or too expensive to
implement or integrate.

I'm not saying that Noah's proposed change is in any way impossible to
implement, but as a member of a team which maintains three OpenID
implementations, the cost is going to be a factor for me.  Most (if not
all) of the editors of the OpenID specification(s) to date have been
directly involved in implementation, and I doubt I am alone in this.

(And yes, I do recognize that I have, in the past, argued in favor of
things that were a lot more complex than this.  It's one factor among
many.)

 - Kevin


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


Re: Problems with OpenID and TAG httpRange-14

2008-03-20 Thread Noah Slater
On Thu, Mar 20, 2008 at 12:42:45PM +1100, Manger, James H wrote:
 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.

Thank you for your enlightened response, a lot of that makes sense.

It is my opinion however that you should consider 302, 303 and 307 redirects in
the same boat for the purposes of making changes to the specification/errata.

--
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-20 Thread Noah Slater
On Wed, Mar 19, 2008 at 08:59:24PM -0700, Johnny Bufu wrote:
 Yes, it is.
[snip]
 The new claimed_id URL is the address of the discovered information
 (which is of interest to the RPs in this case).

No, it really isn't.

Your argument, as far as I understand it, is that HTTP redirects imply the
original URI has an identity relationship final URI. You are using the example
of the address bar in a browser to illustrate this, i.e. I type in X and
eventually it changes to Y, so X must equal Y.

This is of course false, as explicitly stated in the HTTP specification:

  RFC 2616 § 10.3.3 302 Found

  The requested resource resides temporarily under a different URI.
  Since the redirection might be altered on occasion, the client SHOULD
  continue to use the Request-URI for future requests.

  RFC 2616 § 10.3.4 303 See Other

  The response to the request can be found under a different URI and
  SHOULD be retrieved using a GET method on that resource. This method
  exists primarily to allow the output of a POST-activated script to
  redirect the user agent to a selected resource. The new URI is not a
  substitute reference for the originally requested resource.

  RFC 2616 § 10.3.8 307 Temporary Redirect

  The requested resource resides temporarily under a different URI.
  Since the redirection MAY be altered on occasion, the client SHOULD
  continue to use the Request-URI for future requests.

In each case it is explicit that the new URI is not a replacement for the
original URI (303 See Other) or is only a temporary replacement for the
original URI (302 Found, 307 Temporary Redirect).

To argue that because a web browser follows redirects these semantics must not
be true is a gross over-simplification of the facts.

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-20 Thread Johnny Bufu

On 20-Mar-08, at 4:40 AM, Noah Slater wrote:

 On Wed, Mar 19, 2008 at 08:59:24PM -0700, Johnny Bufu wrote:
 Yes, it is.
 [snip]
 The new claimed_id URL is the address of the discovered information
 (which is of interest to the RPs in this case).

 No, it really isn't.

 Your argument, as far as I understand it, is that HTTP redirects  
 imply the
 original URI has an identity relationship final URI. You are using  
 the example
 of the address bar in a browser to illustrate this, i.e. I type in  
 X and
 eventually it changes to Y, so X must equal Y.

Not at all! My argument is, rather:

X and Y are two different things, with two different meanings. If  
the browsers are allowed to use Y as they deem appropriate, there's  
no reason why OpenID discovery can't do the same.

Where the semantic defined by OpenID for X and Y is:
User-supplied ID: X
Claimed ID: Y

And by the browsers:
URL typed in by the user: X
address of the displayed response: Y

 This is of course false, as explicitly stated in the HTTP  
 specification:

It would be, if OpenID said that User-supplied ID must take the value  
of Y.  Instead, it defines a new entity (Claimed ID) and assigns the  
value of Y to it.

I'm arguing that this assignment is not under the scope of the HTTP  
spec, and haven't yet seen an explanation of why it would be. This  
part has to be explained before quoting from the HTTP spec.

I also see no flaw in the above parallel with the browsers. Your  
argument seems to give browsers different privileges than to OpenID  
discovery, and I fail to see a good reason for this.


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 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


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


Re: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-11 Thread Noah Slater
On Mon, Mar 10, 2008 at 10:46:38AM -0700, Drummond Reed wrote:
 It doesn't mean it won't get looked at or discussed here. However any
 formal changes to the specifications must wait until these WGs are started.

Great.

 I'll bring it up at the next OpenID Foundation board meeting (this Thursday)
 so board members are aware of this issue.

Thank you, I really appreciate your efforts.

I will stick around on this list and wait for any potential updates.

Thanks again.

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


RE: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).
 
 Okay, thank you.
 
  Once those groups start, they will each have dedicated mailing lists. In
  the meantime, this is the list for discussing any spec issues. So far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.
 
 Im a little confused about what this means. Does this mean that this issue
 will not get properly looked at until such time as the new WGs have been
 set up?

It doesn't mean it won't get looked at or discussed here. However any
formal changes to the specifications must wait until these WGs are started.

 Is there anywhere further to go from here?

No, this is the right place, and until the WGs are started, any discussion
should take place on this list.

I'll bring it up at the next OpenID Foundation board meeting (this Thursday)
so board members are aware of this issue.

=Drummond 

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


RE: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
Brad,

 

You are correct, the OIDF is not a technical forum. Its responsibility is to
help facilitate the operation of the technical forum and the applicable IPR
policy. The issue I was pointing out was that since the new IPR policy was
adopted in December, which calls for explicit workgroups for each spec, no
place has it been published how those WGs can be formed and operated by
community members in accordance with the IPR policy.

 

So none of this is under the control of the OIDF, but it is their
responsibility to help community members make it happen. I just sent a note
the OIDF board mailing list suggesting this is something that needs
attention on the call this week.

 

=Drummond 

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad
Fitzpatrick
Sent: Monday, March 10, 2008 11:01 AM
To: Drummond Reed
Cc: Noah Slater; specs@openid.net; [EMAIL PROTECTED]
Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14

 

Drummond,

I was under the impression that the OpenID Foundation wasn't a technical
forum.  Is that not true?

- Brad

On Mon, Mar 10, 2008 at 10:46 AM, Drummond Reed [EMAIL PROTECTED]
wrote:

 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14


  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).

 Okay, thank you.

  Once those groups start, they will each have dedicated mailing lists. In
  the meantime, this is the list for discussing any spec issues. So far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.

 Im a little confused about what this means. Does this mean that this issue
 will not get properly looked at until such time as the new WGs have been
 set up?

It doesn't mean it won't get looked at or discussed here. However any
formal changes to the specifications must wait until these WGs are started.


 Is there anywhere further to go from here?

No, this is the right place, and until the WGs are started, any discussion
should take place on this list.

I'll bring it up at the next OpenID Foundation board meeting (this Thursday)
so board members are aware of this issue.

=Drummond


___
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: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread David Recordon
I don't see why changes would really need to wait, if there is an  
interested group of people then lets spin up a mailing list and get  
participants to agree to the IP policy.

The entire goal of having working groups and seperate mailing lists  
is to help ensure that future OpenID specs are not encumbered with  
intellectual property issues.  The easiest, and most common, way to do  
this is creating seperate technical working mailing lists based around  
related topics or a specification.  This allows people to choose where  
they wish to participate since the requirement of posting to one of  
these lists is agreeing that your contributions are being made under  
the OpenID IPR Policy.

This list (specs@openid.net) is a great place to identity issues that  
need addressing and figuring out who wants to work on solving them.   
Once that happens, I have no problem helping to make it legit so  
that the resulting spec is good from an IP perspective.

--David

On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote:

 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14

 Noah, you are in the right place (and the General list is the wrong
 place, which is why I have removed that cc).

 Okay, thank you.

 Once those groups start, they will each have dedicated mailing  
 lists. In
 the meantime, this is the list for discussing any spec issues. So  
 far
 one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
 the thread you started.

 Im a little confused about what this means. Does this mean that  
 this issue
 will not get properly looked at until such time as the new WGs have  
 been
 set up?

 It doesn't mean it won't get looked at or discussed here. However  
 any
 formal changes to the specifications must wait until these WGs are  
 started.

 Is there anywhere further to go from here?

 No, this is the right place, and until the WGs are started, any  
 discussion
 should take place on this list.

 I'll bring it up at the next OpenID Foundation board meeting (this  
 Thursday)
 so board members are aware of this issue.

 =Drummond

 ___
 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: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
Exactly, David, that's the process I was referring to.

It should be as lightweight as possible.

I guess the main question is, is there sufficient interest in either a
bugfix release or a more significant new release to start up a mailing list
on OpenID Authentication yet?

=Drummond 

 -Original Message-
 From: David Recordon [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 12:15 PM
 To: Drummond Reed; Brad Fitzpatrick
 Cc: Noah Slater; OpenID specs list; DeWitt Clinton
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
 I don't see why changes would really need to wait, if there is an
 interested group of people then lets spin up a mailing list and get
 participants to agree to the IP policy.
 
 The entire goal of having working groups and seperate mailing lists
 is to help ensure that future OpenID specs are not encumbered with
 intellectual property issues.  The easiest, and most common, way to do
 this is creating seperate technical working mailing lists based around
 related topics or a specification.  This allows people to choose where
 they wish to participate since the requirement of posting to one of
 these lists is agreeing that your contributions are being made under
 the OpenID IPR Policy.
 
 This list (specs@openid.net) is a great place to identity issues that
 need addressing and figuring out who wants to work on solving them.
 Once that happens, I have no problem helping to make it legit so
 that the resulting spec is good from an IP perspective.
 
 --David
 
 On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote:
 
  -Original Message-
  From: Noah Slater [mailto:[EMAIL PROTECTED]
  Sent: Monday, March 10, 2008 1:43 AM
  To: Drummond Reed
  Cc: specs@openid.net
  Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).
 
  Okay, thank you.
 
  Once those groups start, they will each have dedicated mailing
  lists. In
  the meantime, this is the list for discussing any spec issues. So
  far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.
 
  Im a little confused about what this means. Does this mean that
  this issue
  will not get properly looked at until such time as the new WGs have
  been
  set up?
 
  It doesn't mean it won't get looked at or discussed here. However
  any
  formal changes to the specifications must wait until these WGs are
  started.
 
  Is there anywhere further to go from here?
 
  No, this is the right place, and until the WGs are started, any
  discussion
  should take place on this list.
 
  I'll bring it up at the next OpenID Foundation board meeting (this
  Thursday)
  so board members are aware of this issue.
 
  =Drummond
 
  ___
  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: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-09 Thread Noah Slater
On Tue, Mar 04, 2008 at 05:08:19PM +, Noah Slater wrote:
 There are some issues with the OpenID specification and how it interoperates
 with URI redirects according to RFC2616 and httpRange-14.

Will any members of the OpenID working group care to comment?

Does someone know how to directly bring this to the WG's attention?

--
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-04 Thread Noah Slater
Hello again,

Firstly, sorry for the double post, the OpenID.net homepage does not
clearly indicate that specs@openid.net is a mailing list. However, it has come
to my attention that the mailing list software has truncated my message

  http://openid.net/pipermail/general/2008-March/004217.html
  http://openid.net/pipermail/specs/2008-March/002219.html

For the reference of people using mailman's web interface and incase the
mailing list software truncated the emails as well I had originally cited the
following references:

From the OpenID specification [1]:

  Consumers MUST canonicalize the Identifier URL, following redirects, and note
  the final URL. The final, canonicalized URL is the End User's Identifier.

From RFC2616 [2] (emphasis added in upper case):

  10.3.4 303 See Other

  The response to the request can be found under a different URI and
  SHOULD be retrieved using a GET method on that resource. This method
  exists primarily to allow the output of a POST-activated script to
  redirect the user agent to a selected resource. THE NEW URI IS NOT A
  SUBSTITUTE REFERENCE FOR THE ORIGINALLY REQUESTED RESOURCE. The 303
  response MUST NOT be cached, but the response to the second
  (redirected) request might be cacheable.

From the TAG's findings [3] (emphasis added in upper case):

  According to the HTTP specification, a response code of 303 indicates that
  the response to the request can be found under a different URI  It
  provides the URI where we can look for that response. It's worth noting that
  although 303 has the role of redirecting user agents after script processing
  following POST requests, the specification does not limit it to that role.

  Importantly, the specification also states that The new URI is not a
  substitute reference for the originally requested resource. IN OTHER WORDS,
  RESPONSES CONTAINING THIS CODE DIRECT US TO RELATED MATERIAL. IF WE
  DEREFERENCE THE SUPPLIED URI AND RECEIVE A REPRESENTATION, IT IS CLEAR THAT
  THE REPRESENTATION RELATES TO THE URI WE WERE GIVEN IN THE 303 RESPONSE, AND
  NOT TO THE URI THAT LED TO THE 303 RESPONSE. IN PARTICULAR, WE'RE NOT BEING
  MISLEAD INTO THINKING THAT THE ORIGINAL URI ITSELF HAS REPRESENTATIONS.

I am sorry if this information has reached you twice now.

Thanks,

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