Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA63A6C33 for ; Tue, 29 Jun 2010 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRT8WA8PXGUp for ; Tue, 29 Jun 2010 12:31:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2DE063A6C07 for ; Tue, 29 Jun 2010 12:31:29 -0700 (PDT) Received: (qmail 3700 invoked from network); 29 Jun 2010 19:31:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 19:31:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 29 Jun 2010 12:31:11 -0700 From: Eran Hammer-Lahav To: Yaron Goland , William Mills , Torsten Lodderstedt Date: Tue, 29 Jun 2010 12:31:16 -0700 Thread-Topic: [OAUTH-WG] OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRggARizoCAA7n10IAAByYwgAFfxjCAAAC4UA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com><7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> <012AB2B223CB3F4BB846962876F47217059B677B@SNV-EXVS08.ds.corp.yahoo.com> <7C01E631FF4B654FA1E783F1C0265F8C579D21BD@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D21BD@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 19:32:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is. 401 without it is not. The discovery spec should spell out how to include it with a 200 response w= hen additional, private data is available. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Tuesday, June 29, 2010 12:28 PM To: William Mills; Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? This then goes back to one of my original posts which is - Is www-authentic= ate legal on a non-401 response? I honestly don't know. From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, June 28, 2010 3:30 PM To: Yaron Goland; Torsten Lodderstedt Cc: OAuth WG Subject: RE: [OAUTH-WG] OAuth discovery draft? In the SASL stuff I'm working on I was presuming I'd use the WWW-Authentica= te header for returning the discovery info. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron 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 OA= uth token endpoint is just a tiny part of that state. When we want to retur= n part of the state we typically use either explicit headers (a la byte ran= ges) 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 t= o 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, kn= ock on the front door and ask 'what are you and what can you do?' So it see= ms to me we should start with OPTIONS. But this does bring up a problem - n= obody 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 th= e 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 standar= ds can build on top of. So we have a choice when it comes to using OPTIONS. We can return data in t= he 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 probab= ly 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?) a= nd 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:torsten@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-Authent= icate 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 s= uggested) 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 >: No objections on my part. I would rather have a smaller core spec with feat= ures that everyone agrees on. BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-aut= henticate'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. T= he 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 wher= e their token issuer location is they would want to fire off an OPTIONS req= uest 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 th= is problem is to just return www-authenticate on a 200 response to an OPTIO= NS request. Thoughts? Thanks, Yaron From: Eran Hammer-Lahav [mailto:eran@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 con= sider merging them later on when they reach an equal level of stability. Bu= t overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, "Yaron Goland" > 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 loca= tion 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 an= d 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 t= o walk up to a service and find out where its token server is. Does that re= ally 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 =3D=3D A. In the future= I hope to see extensions to OAuth that enable what I'm terming 'full deleg= ation'. But personally I'm really happy that OAuth has the X=3D=3DA restric= tion. It simplifies a whole host of issues and satisfies a really important= use case. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@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 inclu= des > 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.Manger@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" > > 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 ta= gged: > > "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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= It is. 401 without it is not.

 

The disc= overy spec should spell out how to include it with a 200 response when addi= tional, private data is available.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf Of Yaron Goland
Sent: Tues= day, June 29, 2010 12:28 PM
To: William Mills; Torsten Loddersted= t
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery = draft?

 

This then goes back to one of my origina= l posts which is – Is www-authenticate legal on a non-401 response? I= honestly don’t know.

 

= From:= William Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, June = 28, 2010 3:30 PM
To: Yaron Goland; Torsten Lodderstedt
Cc:<= /b> OAuth WG
Subject: RE: [OAUTH-WG] OAuth discovery draft?<= /o:p>

 

In the SASL stuff I'm working on I was presuming I'd use = the WWW-Authenticate header for returning the discovery info.

 

F= rom: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of Yaron Goland
Sent: Monday, June 28, 2010 3:10 PM
To= : Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OA= UTH-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 wa= nt 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 c= ontrol 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 o= f scenario.

 

OPTIONS is actually the officiall= y blessed way to walk up to a resource, knock on the front door and ask = 216;what are you and what can you do?’ So it seems to me we should st= art with OPTIONS. But this does bring up a problem – nobody ever real= ly defined a response body for OPTIONS. RFC 2616 explicitly defined the leg= ality of such a body but no standard was defined for what the body should l= ook like. This is an issue because if someone does define a body for OPTION= S 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 differ= ent OPTIONS responses live together?) and get that standardized. Then we ca= n write a second RFC to define how our specific data would be carried in OP= TIONS.

 

      &n= bsp;         Thoughts?

 

         &= nbsp;           &nbs= p;          Yaron

 

From: Torsten Lodderstedt [mailto:torsten@lod= derstedt.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-Auth= enticate Header is the right representation for this kind of data. What abo= ut a JSON or XML document returned in response to an OPTIONS request (as you suggested) or a GET request with a certa= in content type in its ACCEPT Header?

 

regard= s,

Torsten. 


Am 23.06.2010 um 20:20 schrieb Yaron Goland <<= a href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com>:

No objections on my part. I would rather have a small= er core spec with features that everyone agrees on.

 

BTW, a thought for th= e discovery draft – RFC 2616/2617 only defines www-authenticate’= ;s semantics in the context of a 401. It’s unclear from the draft wha= t 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 wan= ts to talk to an endpoint they know supports OAuth and need to know where t= heir token issuer location is they would want to fire off an OPTIONS reques= t to the resource and find out from the response where the issuer is and wh= at 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.

 

          &nb= sp;     Thoughts?

&n= bsp;

      = ;            &n= bsp;            = ; Thanks,

 

          &nb= sp;            =             &nb= sp;            Yaron=

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 23, 2010 11:04 AM
To: Yaron Goland; Ja= mes Manger; OAuth WG
Subject: Re: OAuth discovery draft?

 

I think the core work is pre= tty stable now, unlike the discovery bits which (while simple) are not enjo= ying the same level of consensus. I think it is much more practical to prop= ose 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 A= M, "Yaron Goland" <yar= ong@microsoft.com> wrote:

I've been noodling [1] a lo= t 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 endpoi= nt'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-authen= ticate 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 b= e 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?
&nb= sp;       Thanks,
   &= nbsp;           &nbs= p;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 bun= ch of other much more in-depth articles on particular subjects touched on i= n the main article.

[2] I define 'full delegation' as "User X o= f Service Y grants permission Z to User A of Service B". Currently OAu= th requires X =3D=3D A. In the future I hope to see extensions to OAuth tha= t enable what I'm terming 'full delegation'. But personally I'm really happ= y that OAuth has the X=3D=3DA restriction. It simplifies a whole host of is= sues and satisfies a really important use case.

> -----Original M= essage-----
> From: oauth-b= ounces@ietf.org [mailto:oauth= -bounces@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: [OAUT= H-WG] OAuth discovery draft?
>
> Yes, it's on my desk and not y= et 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 we= ek and focus on that next.
>
> EHL
>
> > -----Or= iginal Message-----
> > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=
> > Sent: Monday, June 21, 2010 8:03 PM
> > To: Eran Ham= mer-Lahav; OAuth WG (oauth@ietf.org)<= br>> > Subject: OAuth discovery draft?
> >
> > Eran= ,
> >
> > There have been a few mentions recently of an O= Auth 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)" s= aid:
> >
> > >> 6.1.1. - describing the WWW-Authent= icate response header
> > >>
> > >> - Discove= ry needed for various elements
> > >
> > > Yes. Tha= t's for the discovery draft.
> >
> >
> > A wiki = page on "Future OpenID Technical Requirements"
> > <<= a href=3D"http://wiki.openid.net/Future-OpenID-Technical-Requirements">http= ://wiki.openid.net/Future-OpenID-Technical-Requirements> says:
&g= t; >
> > > 6) IdP Discovery
> > >
> > &= gt;    * Much of this will be covered by OAuth2 Discovery,> > >      however OIC may need to defi= ne 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&= quot;, "discouraged from
> > implementing", "no upd= ate 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/listinf= o/oauth

_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_--