So I was thinking about how to fit this into something like AtomPub. It works okay but I stumbled on POST and DELETE operations:
Case #1: I do a GET on an AtomPub service document, because it might be public and I don't want to do extra round trips on unnecessary discovery. I get back a 401 response with an X-XRDS-Location: header that points me at the discovery document, and a WWW-Authenticate: OAuth header. Since I'm a OAuth+XRDS-Simple client, I understand both, go off and do discovery, authenticate, then come back and re-do the GET with an Authorization: header. OK, simple.
Case #2: I do a POST to an AtomPub collection. It returns a 401 response. But there's no X-XRDS-Location: header, because the workflow only talks about HEAD and GET. So I guess I turn around and do a HEAD: to see if there's an X-XRDS-Location: available? Seems awkward.
This case doesn't arise in OpenID because nobody is POSTing to OpenID URLs (I think). The situation is different for general resources.
I don't think it would make sense to try to do content-type negotiation for POST or DELETE, but X-XRDS-Location: could easily provide a useful pointer on any 401 response. However, I'm not sure how this meshes with XRDS concepts. I do think that avoiding unnecessary round trips is important, though in this case it's only on authentication misses so it's not horrible. But, it seems awkward and unnecessary since you can easily send a header back on a 401 response.
> After reading and discussing all the feedback received for the first > draft, I am excited to publish the second draft. I hope this will get > some activity going in this list...
This may stem from a bigger question - how do you know what endpoint to hit for APP? Wherever that is specified it should specify OAuth. Just a thought.
On Wed, Apr 9, 2008 at 5:15 PM, John Panzer <jpan...@acm.org> wrote: > > So I was thinking about how to fit this into something like AtomPub. It > works okay but I stumbled on POST and DELETE operations: > > Case #1: I do a GET on an AtomPub service document, because it might be > public and I don't want to do extra round trips on unnecessary > discovery. I get back a 401 response with an X-XRDS-Location: header > that points me at the discovery document, and a WWW-Authenticate: OAuth > header. Since I'm a OAuth+XRDS-Simple client, I understand both, go off > and do discovery, authenticate, then come back and re-do the GET with an > Authorization: header. OK, simple. > > Case #2: I do a POST to an AtomPub collection. It returns a 401 > response. But there's no X-XRDS-Location: header, because the workflow > only talks about HEAD and GET. So I guess I turn around and do a HEAD: > to see if there's an X-XRDS-Location: available? Seems awkward. > > This case doesn't arise in OpenID because nobody is POSTing to OpenID > URLs (I think). The situation is different for general resources. > > I don't think it would make sense to try to do content-type negotiation > for POST or DELETE, but X-XRDS-Location: could easily provide a useful > pointer on any 401 response. However, I'm not sure how this meshes with > XRDS concepts. I do think that avoiding unnecessary round trips is > important, though in this case it's only on authentication misses so > it's not horrible. But, it seems awkward and unnecessary since you can > easily send a header back on a 401 response. > > John > > > Eran Hammer-Lahav wrote: > > http://www.hueniverse.com/hueniverse/2008/04/oauth-discovery.html > > > > After reading and discussing all the feedback received for the first > > draft, I am excited to publish the second draft. I hope this will get > > some activity going in this list... > > > > EHL > > > > > > > > > >
The way it should work is always return the X-XRDS-Location header on any result for a resource supporting discovery. If someone needs to perform discovery on a non GET/non-safe method, they should use HEAD. That implies requiring HEAD support on any non-GET resource.
So I would suggest to require the header for all discoverable resource replies, and to support HEAD on any resource that is not GET. But this leaves the problem of using different discovery location for different methods on the same URI...
-----Original Message----- From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of John Panzer Sent: Wednesday, April 09, 2008 5:16 PM To: oauth-extensions@googlegroups.com; xrds-simple@googlegroups.com Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
So I was thinking about how to fit this into something like AtomPub. It works okay but I stumbled on POST and DELETE operations:
Case #1: I do a GET on an AtomPub service document, because it might be public and I don't want to do extra round trips on unnecessary discovery. I get back a 401 response with an X-XRDS-Location: header that points me at the discovery document, and a WWW-Authenticate: OAuth header. Since I'm a OAuth+XRDS-Simple client, I understand both, go off and do discovery, authenticate, then come back and re-do the GET with an Authorization: header. OK, simple.
Case #2: I do a POST to an AtomPub collection. It returns a 401 response. But there's no X-XRDS-Location: header, because the workflow only talks about HEAD and GET. So I guess I turn around and do a HEAD: to see if there's an X-XRDS-Location: available? Seems awkward.
This case doesn't arise in OpenID because nobody is POSTing to OpenID URLs (I think). The situation is different for general resources.
I don't think it would make sense to try to do content-type negotiation for POST or DELETE, but X-XRDS-Location: could easily provide a useful pointer on any 401 response. However, I'm not sure how this meshes with XRDS concepts. I do think that avoiding unnecessary round trips is important, though in this case it's only on authentication misses so it's not horrible. But, it seems awkward and unnecessary since you can easily send a header back on a 401 response.
> After reading and discussing all the feedback received for the first > draft, I am excited to publish the second draft. I hope this will get > some activity going in this list...
Stephen Paul Weber wrote: > This may stem from a bigger question - how do you know what endpoint > to hit for APP? Wherever that is specified it should specify OAuth. > Just a thought.
This doesn't work in all situations. You could have, for example, followed a <link rel="edit" > link from a non-editable syndicated Atom feed in order to edit the source entry. At the end of the day, the resource needs to be able to stand for (by?) itself.
Nothing that says the XRDS doc couldn't be linked to from the Atom service document as well, though.
> On Wed, Apr 9, 2008 at 5:15 PM, John Panzer <jpan...@acm.org> wrote:
> > So I was thinking about how to fit this into something like AtomPub. It > > works okay but I stumbled on POST and DELETE operations:
> > Case #1: I do a GET on an AtomPub service document, because it might be > > public and I don't want to do extra round trips on unnecessary > > discovery. I get back a 401 response with an X-XRDS-Location: header > > that points me at the discovery document, and a WWW-Authenticate: OAuth > > header. Since I'm a OAuth+XRDS-Simple client, I understand both, go off > > and do discovery, authenticate, then come back and re-do the GET with an > > Authorization: header. OK, simple.
> > Case #2: I do a POST to an AtomPub collection. It returns a 401 > > response. But there's no X-XRDS-Location: header, because the workflow > > only talks about HEAD and GET. So I guess I turn around and do a HEAD: > > to see if there's an X-XRDS-Location: available? Seems awkward.
> > This case doesn't arise in OpenID because nobody is POSTing to OpenID > > URLs (I think). The situation is different for general resources.
> > I don't think it would make sense to try to do content-type negotiation > > for POST or DELETE, but X-XRDS-Location: could easily provide a useful > > pointer on any 401 response. However, I'm not sure how this meshes with > > XRDS concepts. I do think that avoiding unnecessary round trips is > > important, though in this case it's only on authentication misses so > > it's not horrible. But, it seems awkward and unnecessary since you can > > easily send a header back on a 401 response.
> > > After reading and discussing all the feedback received for the first > > > draft, I am excited to publish the second draft. I hope this will get > > > some activity going in this list...
On 10/04/2008, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> The way it should work is always return the X-XRDS-Location header on any > result for a resource supporting discovery. If someone needs to perform > discovery on a non GET/non-safe method, they should use HEAD. That implies > requiring HEAD support on any non-GET resource.
This seems unnecessarily complicated. Discovery is provided by the XRDS doc, right? So any resource supporting discovery will have an "application/xrds+xml" representation. To obtain that representation a GET should be done with that media type in the Accept header. If the doc isn't available at that URI, the server should issue a 3xx with a Location header pointing to the appropriate URL. A HEAD would give you the same info.
Ok, I understand that you wish to retain the X-XRDS-Location bits to stay consistent with Yadis etc. I don't see any reason not to return that header as well. The advantage of using the approach above is that the server might have a different type of service doc available that the client would understand, and deliver it again using standard web approaches (i.e. the client might have application/atomsvc+xml with a lower priority in the Accept).
So I would suggest to require the header for all discoverable resource
> replies, and to support HEAD on any resource that is not GET. But this > leaves the problem of using different discovery location for different > methods on the same URI...
This proposal is really a more restrictive version of Yadis. It implies is that Consumers MUST use the Accept header (while Yadis makes this optional). Basically, all the Consumer does is ask for the XRDS representation of the resource and either gets it or redirected to it. If at the end of the redirects (can be none) it fails to find a valid xrds content type, is should look for other hints (X-XRDS-Location header or HTML meta).
I like this a lot. The big question is if this will cause problems for OpenID. I don't think so because the burden of this change is on the Consumer (RP in the OpenID case) which should be able to use the Accept header. If the hosting server for the OpenID landing page cannot support the Accept header, it still has the other fallbacks.
I'm going to make this change unless someone has a reason why this is a problem.
---
However, this still doesn't address the problem John Panzer raised which is, removing the need for a second HTTP request when getting a 401 response. Since this is specific to the OAuth flow, would it make sense to require/recommend in OAuth Discovery that when a request is unauthorized and is protected by OAuth, the SP SHOULD include the X-XRDS-Location header?
EHL
From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of Danny Ayers Sent: Thursday, April 10, 2008 2:27 AM To: xrds-simple@googlegroups.com Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
On 10/04/2008, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote:
The way it should work is always return the X-XRDS-Location header on any result for a resource supporting discovery. If someone needs to perform discovery on a non GET/non-safe method, they should use HEAD. That implies requiring HEAD support on any non-GET resource.
This seems unnecessarily complicated. Discovery is provided by the XRDS doc, right? So any resource supporting discovery will have an "application/xrds+xml" representation. To obtain that representation a GET should be done with that media type in the Accept header. If the doc isn't available at that URI, the server should issue a 3xx with a Location header pointing to the appropriate URL. A HEAD would give you the same info.
Ok, I understand that you wish to retain the X-XRDS-Location bits to stay consistent with Yadis etc. I don't see any reason not to return that header as well. The advantage of using the approach above is that the server might have a different type of service doc available that the client would understand, and deliver it again using standard web approaches (i.e. the client might have application/atomsvc+xml with a lower priority in the Accept).
So I would suggest to require the header for all discoverable resource replies, and to support HEAD on any resource that is not GET. But this leaves the problem of using different discovery location for different methods on the same URI...
Is there any reason we couldn’t return an XRDS discovery doc in the body of a 401 response – regardless of the request method (GET, POST, DELETE…), or Accept MIME-types? That removes all unnecessary requests.
I would still prefer putting the required authentication details in a WWW-Authenticate header, but putting them in the body is probably the next best thing.
James Manger
________________________________
From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, 22 June 2008 4:35 PM
To: xrds-simple@googlegroups.com
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
…
However, this still doesn’t address the problem John Panzer raised which is, removing the need for a second HTTP request when getting a 401 response. Since this is specific to the OAuth flow, would it make sense to require/recommend in OAuth Discovery that when a request is unauthorized and is protected by OAuth, the SP SHOULD include the X-XRDS-Location header?
For a 401 response, you could, though perhaps a standard error document which includes an XRDS link would be a better choice.
But for a non-401 response which includes a WWW-Authenticate: challenge, you cannot. This would be the case for example for a feed which is personalized/filtered based on the auth info if present, but shows public data otherwise. (This is the case for Blogger feeds, for example.)
> Is there any reason we couldn’t return an XRDS discovery doc in the > body of a 401 response – regardless of the request method (GET, POST, > DELETE…), or Accept MIME-types? That removes all unnecessary requests.
> I would still prefer putting the required authentication details in a > WWW-Authenticate header, but putting them in the body is probably the > next best thing.
> However, this still doesn’t address the problem John Panzer raised > which is, removing the need for a second HTTP request when getting a > 401 response. Since this is specific to the OAuth flow, would it make > sense to require/recommend in OAuth Discovery that when a request is > unauthorized and is protected by OAuth, the SP SHOULD include the > X-XRDS-Location header?
I’m trying to find a way for a resource to indicate it supports XRDS-Simple discovery. I think the best way to do it is by always including the X-XRDS-Location header for any URI that can also serve an XRDS representation. This way, it will be made available for the non GET methods, as well as 401s. I am also thinking that it might be cool to allow some sort of “self” indicator so that it can save a couple of extra bytes in the header by doing something like:
X-XRDS-Location: #
X-XRDS-Location: self
etc.
Which means, use the same URI with an Accept header sets to xml+xrds.
Thoughts?
EHL
From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of John Panzer
Sent: Sunday, June 22, 2008 8:51 PM
To: xrds-simple@googlegroups.com
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
For a 401 response, you could, though perhaps a standard error document which includes an XRDS link would be a better choice.
But for a non-401 response which includes a WWW-Authenticate: challenge, you cannot. This would be the case for example for a feed which is personalized/filtered based on the auth info if present, but shows public data otherwise. (This is the case for Blogger feeds, for example.)
Manger, James H wrote:
Is there any reason we couldn’t return an XRDS discovery doc in the body of a 401 response – regardless of the request method (GET, POST, DELETE…), or Accept MIME-types? That removes all unnecessary requests.
I would still prefer putting the required authentication details in a WWW-Authenticate header, but putting them in the body is probably the next best thing.
James Manger
________________________________
From: xrds-simple@googlegroups.com<mailto:xrds-simple@googlegroups.com> [mailto:xrds-simple@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, 22 June 2008 4:35 PM
To: xrds-simple@googlegroups.com<mailto:xrds-simple@googlegroups.com>
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
…
However, this still doesn’t address the problem John Panzer raised which is, removing the need for a second HTTP request when getting a 401 response. Since this is specific to the OAuth flow, would it make sense to require/recommend in OAuth Discovery that when a request is unauthorized and is protected by OAuth, the SP SHOULD include the X-XRDS-Location header?
Include the full URI in the X-XRDS-Location header.
Clients can be smart enough to notice that the URI matches the current request if they really want to.
> a standard error document which includes an XRDS link would be a better choice.
The X-XRDS-Location header (and HTML equivalent?) already provides a link so
only including the XRDS doc itself would be an extra benefit (which is only applicable on errors as John said).
James Manger
________________________________
From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Monday, 23 June 2008 2:00 PM
To: xrds-simple@googlegroups.com
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
I’m trying to find a way for a resource to indicate it supports XRDS-Simple discovery. I think the best way to do it is by always including the X-XRDS-Location header for any URI that can also serve an XRDS representation. This way, it will be made available for the non GET methods, as well as 401s. I am also thinking that it might be cool to allow some sort of “self” indicator so that it can save a couple of extra bytes in the header by doing something like:
X-XRDS-Location: #
X-XRDS-Location: self
etc.
Which means, use the same URI with an Accept header sets to xml+xrds.
Thoughts?
EHL
From: xrds-simple@googlegroups.com [mailto:xrds-simple@googlegroups.com] On Behalf Of John Panzer
Sent: Sunday, June 22, 2008 8:51 PM
To: xrds-simple@googlegroups.com
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
For a 401 response, you could, though perhaps a standard error document which includes an XRDS link would be a better choice.
But for a non-401 response which includes a WWW-Authenticate: challenge, you cannot. This would be the case for example for a feed which is personalized/filtered based on the auth info if present, but shows public data otherwise. (This is the case for Blogger feeds, for example.)
Manger, James H wrote:
Is there any reason we couldn’t return an XRDS discovery doc in the body of a 401 response – regardless of the request method (GET, POST, DELETE…), or Accept MIME-types? That removes all unnecessary requests.
I would still prefer putting the required authentication details in a WWW-Authenticate header, but putting them in the body is probably the next best thing.
James Manger
________________________________
From: xrds-simple@googlegroups.com<mailto:xrds-simple@googlegroups.com> [mailto:xrds-simple@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, 22 June 2008 4:35 PM
To: xrds-simple@googlegroups.com<mailto:xrds-simple@googlegroups.com>
Subject: [xrds-simple] Re: [oauth-extensions] OAuth Discovery Draft 2 Released
…
However, this still doesn’t address the problem John Panzer raised which is, removing the need for a second HTTP request when getting a 401 response. Since this is specific to the OAuth flow, would it make sense to require/recommend in OAuth Discovery that when a request is unauthorized and is protected by OAuth, the SP SHOULD include the X-XRDS-Location header?
