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 <[email protected]>:
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-authentica
te 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 th
ey know supports OAuth and need to know where their token issuer loc
ation is they would want to fire off an OPTIONS request to the resou
rce and find out from the response where the issuer is and what real
m 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 O
PTIONS request.
Thoughts?
Thanks,
Yaron
From: Eran Hammer-Lahav [mailto:[email protected]]
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 wor
ries about multiple documents.
EHL
On 6/23/10 11:00 AM, "Yaron Goland" <[email protected]> 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: [email protected] [mailto:[email protected]] On
Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, June 21, 2010 9:50 PM
> To: Manger, James H; OAuth WG ([email protected])
> 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:[email protected]]
> > Sent: Monday, June 21, 2010 8:03 PM
> > To: Eran Hammer-Lahav; OAuth WG ([email protected])
> > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
