In the SASL stuff I'm working on I was presuming I'd use the
WWW-Authenticate header for returning the discovery info.
________________________________
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Yaron Goland
Sent: Monday, June 28, 2010 3:10 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?
I believe that GET should be used to return the resource's state
and its OAuth token endpoint is just a tiny part of that state. When we
want to return part of the state we typically use either explicit
headers (a la byte ranges) or a query parameter. Content-types should, I
think, just control the syntax of what is returned, not the subset of
data it contains. So I have to admit that I really don't like using GET
for this sort of scenario.
OPTIONS is actually the officially blessed way to walk up to a
resource, knock on the front door and ask 'what are you and what can you
do?' So it seems to me we should start with OPTIONS. But this does bring
up a problem - nobody ever really defined a response body for OPTIONS.
RFC 2616 explicitly defined the legality of such a body but no standard
was defined for what the body should look like. This is an issue because
if someone does define a body for OPTIONS then they really need to do so
in a way that other standards can build on top of.
So we have a choice when it comes to using OPTIONS. We can
return data in the header in which case all we have to do is just define
the header, submit the RFC and call it day. Or we can use the body but
in that case we probably need to write one spec to define a generic way
to return data in OPTIONS response bodies (e.g. how do different OPTIONS
responses live together?) and get that standardized. Then we can write a
second RFC to define how our specific data would be carried in OPTIONS.
Thoughts?
Yaron
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, June 25, 2010 11:09 PM
To: Yaron Goland
Cc: Eran Hammer-Lahav; James Manger; OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?
I think it should be possible to discover a resource's OAuth
server and its capabilities using a direct Discovery request. I don't
think a WWW-Authenticate Header is the right representation for this
kind of data. What about a JSON or XML document returned in response to
an OPTIONS request (as you suggested) or a GET request with a certain
content type in its ACCEPT Header?
regards,
Torsten.
Am 23.06.2010 um 20:20 schrieb Yaron Goland
<yar...@microsoft.com>:
No objections on my part. I would rather have a smaller
core spec with features that everyone agrees on.
BTW, a thought for the discovery draft - RFC 2616/2617
only defines www-authenticate's semantics in the context of a 401. It's
unclear from the draft what it would mean to return a www-authenticate
header on a 200 response. The reason I care about this is that I think
it makes sense that if someone wants to talk to an endpoint they know
supports OAuth and need to know where their token issuer location is
they would want to fire off an OPTIONS request to the resource and find
out from the response where the issuer is and what realm is being used.
It seems to me that the simplest way to solve this problem is to just
return www-authenticate on a 200 response to an OPTIONS request.
Thoughts?
Thanks,
Yaron
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, June 23, 2010 11:04 AM
To: Yaron Goland; James Manger; OAuth WG
Subject: Re: OAuth discovery draft?
I think the core work is pretty stable now, unlike the
discovery bits which (while simple) are not enjoying the same level of
consensus. I think it is much more practical to propose them as a
separate document and perhaps consider merging them later on when they
reach an equal level of stability. But overall, I'm not too worries
about multiple documents.
EHL
On 6/23/10 11:00 AM, "Yaron Goland"
<yar...@microsoft.com> wrote:
I've been noodling [1] a lot about full delegation in
OAuth [2] and one of the issues that came out of that was the need for
discovering both the location and realm of an endpoint's token server.
But at least for my use cases (which consist of walking up to a service
and making an options request and getting back a www-authenticate
header) all I need back is a realm and a token server URL. In other
words just having one argument added to our www-authenticate header
would be enough to solve the case where someone wants to walk up to a
service and find out where its token server is. Does that really need
its own spec? Or can we just add an argument to www-authenticate in the
current spec?
Thanks,
Yaron
[1] See http://www.goland.org/oauthgenericdelegation/
for an overview of my thinking on full delegation in OAuth. At the very
end are links to a bunch of other much more in-depth articles on
particular subjects touched on in the main article.
[2] I define 'full delegation' as "User X of Service Y
grants permission Z to User A of Service B". Currently OAuth requires X
== A. In the future I hope to see extensions to OAuth that enable what
I'm terming 'full delegation'. But personally I'm really happy that
OAuth has the X==A restriction. It simplifies a whole host of issues and
satisfies a really important use case.
> -----Original Message-----
> From: oauth-boun...@ietf.org
[mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, June 21, 2010 9:50 PM
> To: Manger, James H; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth discovery draft?
>
> Yes, it's on my desk and not yet ready, but I am
working on one. It includes
> your sites proposal among other things. I am trying to
get the core spec
> stable this week and focus on that next.
>
> EHL
>
> > -----Original Message-----
> > From: Manger, James H
[mailto:james.h.man...@team.telstra.com]
> > Sent: Monday, June 21, 2010 8:03 PM
> > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > Subject: OAuth discovery draft?
> >
> > Eran,
> >
> > There have been a few mentions recently of an OAuth
discovery draft.
> > Is there any such draft yet, or is this just a part
that we know needs
> > to be done?
> >
> > The email on "OAuth meeting notes on -05 (with
updates)" said:
> >
> > >> 6.1.1. - describing the WWW-Authenticate response
header
> > >>
> > >> - Discovery needed for various elements
> > >
> > > Yes. That's for the discovery draft.
> >
> >
> > A wiki page on "Future OpenID Technical
Requirements"
> >
<http://wiki.openid.net/Future-OpenID-Technical-Requirements> says:
> >
> > > 6) IdP Discovery
> > >
> > > * Much of this will be covered by OAuth2
Discovery,
> > > however OIC may need to define OpenID
specific features.
> > >...
> > > 17) Simpler discovery
> > >
> > > * See Eran's OAuth Discovery proposal
> >
> >
> > There was an OAuth 1.0 Discovery draft over 2 years
ago, but that is tagged:
> > "expired", "marked as obsolete by its author",
"discouraged from
> > implementing", "no update is expected", "replaced by
the OAuth 2.0
> effort".
> >
> > I know I should write a discovery draft myself.
> >
> > --
> > James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
