Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

n server SHOULD document its scope requirements and default value (if defined). HTH, Marty *From:* Teeter, John [mailto:john.tee...@nist.gov] *Sent:* Monday, February 17, 2014 8:41 AM *To:* Marty Burns; Donald Coffin; Bill Mills; oauth@ietf.org *Cc:* greenbutton-dev *Subject:* Re: [OAUTH-

Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

utton-...@googlegroups.com [mailto:greenbutton-...@googlegroups.com] On Behalf Of Donald Coffin Sent: Sunday, February 16, 2014 8:14 PM To: 'Bill Mills'; oauth@ietf.org Cc: 'greenbutton-dev' Subject: RE: [OAUTH-WG] Scope parameter values for "authorization_code" and "client

Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

Mills [mailto:wmills_92...@yahoo.com] Sent: Saturday, February 15, 2014 8:30 PM To: Donald Coffin; oauth@ietf.org Cc: greenbutton-dev Subject: Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens To tokens themselves don'

Re: [OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

To tokens themselves don't differ based on how they are obtained unless you want them to.  No requirement to match scope to the client ID either, but again it's up to you. You do want to get this right.  The challenge here is that your resource servers have to get updated to support new scopes.

[OAUTH-WG] Scope parameter values for "authorization_code" and "client_credentials" based access tokens

I would like to get the views and comments of the OAuth 2.0 IETF WG on the following design and implementation question: I have an application that supports both "authorization_code" and "client_credentials" based access tokens. The application allows a client to obtain data on a nightly basis

[OAUTH-WG] Scope definition feedback (Yaron Goland)

> 4.1.2. Authorization Response: Comment "The language around scopes in > the document is really frustrating. One only finds out much later in the > document that it is perfectly allowable for an authorization server to more or > less ignore what scopes are submitted and instead to just return

Re: [OAUTH-WG] Scope: why is the format predetermined?

Whoops, turns out we were just abusing scope (ie not in the SAML sense). Sorry; my bad. Laurens ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Scope: why is the format predetermined?

Can you explain your use case a little more, and provide an example of why the current system doesn't work for you? We have had numerous previous discussions about the format of scope, and the spec represents the consensus around how people plan to use them. http://www.ietf.org/mail-archive/web/

[OAUTH-WG] Scope: why is the format predetermined?

Hey, We have a use case for a scope that's more fine-grained/flexible than what you could explain in a set of space-delimited keywords. We would like to encode things like the precision with which some data can be accessed, and the scope sounds like the reasonable place to do that. Of course we

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

th-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Dick Hardt >> Sent: Friday, June 25, 2010 8:50 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> To clar

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

That's coming in -09. EHL > -Original Message- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Friday, June 25, 2010 11:19 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

ck Hardt >> Sent: Friday, June 25, 2010 8:50 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> To clarify, the goal is to reserve a namespace for future use so that near >&g

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

f Dick Hardt > Sent: Friday, June 25, 2010 8:50 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > To clarify, the goal is to reserve a namespace for future use so that near > term > imple

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

> Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > I agree with Dick that the scope should remain out of scope for OAuth. > ;-) Having a shared parameter here gives the illusion of interoperability, but > because there's no common understa

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

would be "https://graph.facebook.com";. >>> >>> To respond to the statement Dick made about having standardized values >>> later there would still be the need to decide about the structure of the >>> values now. One possibility is to just add a pref

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

t;> there would still be the need to decide about the structure of the values >> now. One possibility is to just add a prefix for standardized values that >> are not allowed to be used in other cases, such as "std:". >> >> Ciao >> Hannes >> >>

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

hat are > not allowed to be used in other cases, such as "std:". > > Ciao > Hannes > > >> -Original Message- >> From: ext William Mills [mailto:wmi...@yahoo-inc.com] >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

> > Ciao > Hannes > > >> -Original Message- >> From: ext William Mills [mailto:wmi...@yahoo-inc.com] >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >> Rosenstock; Dick Hardt >> Cc: OAuth WG >

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

in other cases, such as "std:". > > Ciao > Hannes > > > > -Original Message- > > From: ext William Mills [mailto:wmi...@yahoo-inc.com] > > Sent: Thursday, June 24, 2010 8:15 PM > > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas > Rosenstock; Dick Hardt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > I'm in favor of having a spaces separated list of tokens. > The only case I can think of where the client needs to han

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

etf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Thursday, June 24, 2010 3:58 AM > To: ext Lukas Rosenstock; Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > The questio

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

iginal Message- >> From: ext Lukas Rosenstock [mailto:l...@lukasrosenstock.net] >> Sent: Thursday, June 24, 2010 10:49 AM >> To: Dick Hardt >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

I recall there being consensus on the space delimiter to make it so that URIs could be used easily as scope parameters. I know that I, personally, would rather have keywords in our implementation than URIs, so I'm very much in favor of keeping it unspecified. -- justin On Thu, 2010-06-24 at 03:4

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

iao Hannes > -Original Message- > From: ext Lukas Rosenstock [mailto:l...@lukasrosenstock.net] > Sent: Thursday, June 24, 2010 10:49 AM > To: Dick Hardt > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

Wasn't there some concensus that URIs would be good for scope? They have "in-built namespacing" ... Lukas 2010/6/23 Dick Hardt : > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> " >>   scope >>         OPTIONAL.  The scope of the access request expressed as a list >

[OAUTH-WG] Scope :: Was: Extensibility for OAuth?

On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > " > scope > OPTIONAL. The scope of the access request expressed as a list > of space-delimited strings. The value of the "scope" parameter > is defined by the authorization server. If the value c

Re: [OAUTH-WG] Scope - Coming to a Consensus

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, May 03, 2010 6:24 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus > > A comma is a better

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 to option 3 I think the suggestion below from Torsten makes great sense, especially in relation to standardized apis such as mail Mark On 01 May 2010, at 13:36 PM, Eve Maier wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 on option 3. Commas seem slightly cleaner, but can go either way. We should also consider naming this parameter "scopes" if we go with option 3 Evan On Mon, May 3, 2010 at 6:23 AM, Manger, James H < james.h.man...@team.telstra.com> wrote: > A comma is a better separator here. > Allow URIs a

Re: [OAUTH-WG] Scope - Coming to a Consensus

A comma is a better separator here. Allow URIs as scopes -- as long as the chosen URIs don't have commas. This isn't a big restriction on services. [If a service provider really needs to include arbitrary URIs in an authorization URI they can still do so by defining another parameter, say "urls

Re: [OAUTH-WG] Scope - Coming to a Consensus

On 2010-05-01, at 3:48 PM, Luke Shepard wrote: > I agree with approach #3. > > As for the delimiter, I'm fine if the spec wants to do space-delimited. > > Just FYI Facebook will also continue to support and document commas in > addition to whatever the spec says, because spaces are typically

Re: [OAUTH-WG] 'Scope' parameter proposal

I'm intrigued by the idea of returning scopes in the 403 response to a resource. I'll see if we can provide a working example of it. On Apr 23, 2010, at 5:05 PM, Brian Eaton wrote: > On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H > wrote: >> We mustn't drop advertisements (details in 401 resp

Re: [OAUTH-WG] Scope - Coming to a Consensus

I agree with approach #3. As for the delimiter, I'm fine if the spec wants to do space-delimited. Just FYI Facebook will also continue to support and document commas in addition to whatever the spec says, because spaces are typically URL-encoded while commas are considered reserved characters

Re: [OAUTH-WG] Scope - Coming to a Consensus

On 30 Apr 2010, at 11:00 PM, Torsten Lodderstedt wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >> wrote: >> >>> In my opinion, automatic discovery on scope values is as valuable or not >>> valuable as automatic discovery for a

Re: [OAUTH-WG] Scope - Coming to a Consensus

Am 01.05.2010 03:07, schrieb Marius Scurtescu: On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt wrote: In my opinion, automatic discovery on scope values is as valuable or not valuable as automatic discovery for a service API. I would like to echo one of my postings: A scope defines

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 for #3. If the delimiter becomes an issue then: - for application/x-www-form-urlencoded and query parameters we can allow multiple values for this parameter - for json this parameter can be defined as an array Marius On Fri, Apr 30, 2010 at 12:08 PM, Allen Tom wrote: > I vote for #3 > > Th

Re: [OAUTH-WG] Scope - Coming to a Consensus

On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt wrote: > In my opinion, automatic discovery on scope values is as valuable or not > valuable as automatic discovery for a service API. I would like to echo one > of my postings: > > A scope defines the set of permissions a client asks for and t

Re: [OAUTH-WG] Scope - Coming to a Consensus

Piling on: +1 for #3. --justin -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Pelle Braendgaard Sent: Friday, April 30, 2010 2:13 PM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus +1 for #3 Since google

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 for #3 Since google implemented I always thought it an elegant simple way of requesting access. On Fri, Apr 30, 2010 at 4:52 PM, Joseph Smarr wrote: > I also vote for #3. I think our field experience has shown that a) lack of a > standard place to stick scope info in access token requests lea

Re: [OAUTH-WG] Scope - Coming to a Consensus

I also vote for #3. I think our field experience has shown that a) lack of a standard place to stick scope info in access token requests leads to per-provider inconsistencies that further complicate libraries, b) lots of providers do want to offer scoped access tokens (and show the list of scopes b

Re: [OAUTH-WG] Scope - Coming to a Consensus

I vote for #3 There are already plenty of implementations that use a scope parameter: Facebook: http://developers.facebook.com/docs/authentication/ Google: http://code.google.com/apis/accounts/docs/OAuth_ref.html#RequestToken Flickr: (called "perm") http://www.flickr.com/services/api/auth.spec.

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 on option 3. Am 30.04.2010 17:43, schrieb Eran Hammer-Lahav: 3. Space-Delimited Scope Parameter Value Define a 'scope' parameter with value of space-delimited strings (which can include any character that is not a space - the entire parameter value is encoded per the transport rules regard

[OAUTH-WG] Scope - Coming to a Consensus

It's time to decide how we want to treat access token scope in the specification. Note that this discussion is limited to *requesting* an access token with a specific scope and does not include how to decide when a token should be reused against an unfamiliar server (i.e. resource server adverti

Re: [OAUTH-WG] 'Scope' parameter proposal

trol model. BillK From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Panzer Sent: Tuesday, April 27, 2010 12:20 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] 'Scope' parameter proposal The old AOL Blogs API, which used AOL's OpenAut

Re: [OAUTH-WG] 'Scope' parameter proposal

The old AOL Blogs API, which used AOL's OpenAuth service, provided a url= parameter on WWW-Authenticate: challenges: dev.estage.aol.com/aolblogs_api#mozTocId815750

Re: [OAUTH-WG] 'Scope' parameter proposal

Am 24.04.2010 02:05, schrieb Brian Eaton: On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H wrote: We mustn't drop advertisements (details in 401 responses). We mustn't drop the goal of a standard for interoperability. I share the goals, I just don't think that a specification is the

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H wrote: > We mustn't drop advertisements (details in 401 responses). > We mustn't drop the goal of a standard for interoperability. I share the goals, I just don't think that a specification is the way to get there. I think working examples in the

Re: [OAUTH-WG] 'Scope' parameter proposal

This looks about right. EHL > -Original Message- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Friday, April 23, 2010 3:31 PM > To: Manger, James H > Cc: Brian Eaton; Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' pa

Re: [OAUTH-WG] 'Scope' parameter proposal

I suspect the key concept is realising that there can be many authz URIs — and that that is ok. OAuth libraries should support this concept — perhaps by not expecting a single authz URI to be provided in a config file. I fully agree with your statement. Authorization servers may use dif

Re: [OAUTH-WG] 'Scope' parameter proposal

ameter in authz URIs is be quite separate. -- James Manger -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Friday, 23 April 2010 6:50 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] 'Scope' para

Re: [OAUTH-WG] 'Scope' parameter proposal

I'm getting whiplash. :) Some of us are working on UMA implementations based on the ever-changing OAuth substrate, and just discussed being glad we could reuse OAuth's advertisement of these two endpoints rather than inventing our own mechanism. If it goes, I guess we'll have to go back to defi

Re: [OAUTH-WG] 'Scope' parameter proposal

My proposal is just that, a proposal. And it is an attemp to get closer to how most companies plan to use it. We have no consensus on defining a prameter name without defining a value. Got new ideas? EHL On Apr 22, 2010, at 13:50, "Brian Eaton" wrote: > On Thu, Apr 22, 2010 at 12:41 PM, Er

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 12:41 PM, Eran Hammer-Lahav wrote: > Drop the 'scope' parameter as well and we're on the same page. So we have a choice between a) not documenting something that a bunch of providers have already implemented and found useful or b) documenting something that no one has

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav wrote: > This suggests we need to rethink our goal of interop and replace it with > library re-use. > > To me interop means that a client can interact with an unknown server by > simply speaking the protocol (the way an email can be delivered to

Re: [OAUTH-WG] 'Scope' parameter proposal

Drop the 'scope' parameter as well and we're on the same page. EHL > -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, April 22, 2010 12:36 PM > To: Eran Hammer-Lahav > Cc: John Kemp; OAuth WG > Subject: Re: [OAUTH-WG] &

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav wrote: > If we are not going to enable a client to access a protected resource hosted > by an unfamiliar > server, we need to stop pretending this (alone) is about interop. In other > words, if we take > this approach we are mandating paperwork

Re: [OAUTH-WG] 'Scope' parameter proposal

On Apr 22, 2010, at 2:21 PM, Brian Eaton wrote: > On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav > wrote: >> Rules around realms show this is very tricky but unless we update 2617 >> (which we >> are not chartered to do) we are still stuck with realm as a required >> parameter. >> One way

Re: [OAUTH-WG] 'Scope' parameter proposal

oblems keeping 2.0 at the same level. I just think it is premature to give up. EHL > -Original Message- > From: John Kemp [mailto:j...@jkemp.net] > Sent: Thursday, April 22, 2010 11:39 AM > To: Brian Eaton > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] 'Scop

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, April 22, 2010 11:48 AM > On Thu, Apr 22, 2010 at 11:39 AM, John Kemp wrote: > > I agree that 'scope' is something that many SPs want. If they don't > > want it roughly the same way though (something

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 11:39 AM, John Kemp wrote: > I agree that 'scope' is something that many SPs want. If they don't want it > roughly the > same way though (something more than a "bucket of opaque strings with a > standard > name") I don't know if I understand the point to standardizing it.

Re: [OAUTH-WG] 'Scope' parameter proposal

Hi Brian, On Apr 22, 2010, at 1:36 PM, Brian Eaton wrote: > On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav > wrote: >>> The scope doesn't have to match the base URI of the resource which the >>> client tried and got the 401 from? >> >> That's a security issue we need to address (when to tr

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 11:30 AM, Eran Hammer-Lahav wrote: > What makes this so much different from Basic? Instead of using a flow the > browser > simply asks the user for a set of credentials. Once it has a set, it reuses > it based on realm. Those rules aren't practical or correct for most AP

Re: [OAUTH-WG] 'Scope' parameter proposal

, 2010 11:22 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav > wrote: > > Rules around realms show this is very tricky but unless we update 2617 > > (whi

Re: [OAUTH-WG] 'Scope' parameter proposal

On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav wrote: > Rules around realms show this is very tricky but unless we update 2617 (which > we > are not chartered to do) we are still stuck with realm as a required > parameter. > One way to avoid this debate is to simply say that clients should

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, April 22, 2010 10:36 AM > To: Eran Hammer-Lahav > Cc: John Kemp; OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > On Mon, Apr 19, 2010 at 3:17 PM, Er

Re: [OAUTH-WG] 'Scope' parameter proposal

On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav wrote: >> The scope doesn't have to match the base URI of the resource which the >> client tried and got the 401 from? > > That's a security issue we need to address (when to trust the resource server > and reuse an existing token). We need to fi

Re: [OAUTH-WG] 'Scope' parameter proposal

Wednesday, April 21, 2010 1:23 PM > *To:* Eve Maler > *Cc:* jsm...@stanfordalumni.org; OAuth WG > > *Subject:* Re: [OAUTH-WG] 'Scope' parameter proposal > > > > Hi all, > > > > On Tue, Apr 20, 2010 at 6:05 PM, Eve Maler wrote: > > It seems like this proposal "g

Re: [OAUTH-WG] 'Scope' parameter proposal

How about review the proposals? EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chasen Le Hara Sent: Wednesday, April 21, 2010 1:23 PM To: Eve Maler Cc: jsm...@stanfordalumni.org; OAuth WG Subject: Re: [OAUTH-WG] 'Scope' parameter proposal Hi all, On T

Re: [OAUTH-WG] 'Scope' parameter proposal

Hi all, On Tue, Apr 20, 2010 at 6:05 PM, Eve Maler wrote: > It seems like this proposal "goes there" in terms of getting as expressive > as Eran fears, though the addition of the wildcard takes away a good deal of > the pain depending on the particular interface at the endpoint(s). Is there > an

Re: [OAUTH-WG] 'Scope' parameter proposal

nternal structure of the "stuff" without a good reason. -- James Manger > -Original Message- > From: Manger, James H [mailto:james.h.man...@team.telstra.com] > Sent: Monday, April 19, 2010 9:06 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUT

Re: [OAUTH-WG] 'Scope' parameter proposal

iple parties want to support > any of these, now they have an agreed-upon way to do so". And with scope, I > hope by now it's well established that scopes are going to be common and the > status quo badly under-specifies how to query for them and use them. > > Thanks,

Re: [OAUTH-WG] 'Scope' parameter proposal

inal Message- > > From: Dick Hardt [mailto:dick.ha...@gmail.com] > > Sent: Monday, April 19, 2010 8:07 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > > > > > On 2010-04-19, at 9:25

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Monday, April 19, 2010 8:07 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > > On 2010-04-19, at 9:25 AM, Eran Hamme

Re: [OAUTH-WG] 'Scope' parameter proposal

age- > From: Manger, James H [mailto:james.h.man...@team.telstra.com] > Sent: Monday, April 19, 2010 9:06 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] 'Scope' parameter proposal > > >HTTP/1.1 401 Unauthorized > >WWW-Authenticat

Re: [OAUTH-WG] 'Scope' parameter proposal

de generic documentation for the entire endpoint capabilities. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, April 19, 2010 9:25 AM > To: OAuth WG > Subject: [OAUTH-WG] '

Re: [OAUTH-WG] 'Scope' parameter proposal

please, add the scope parameter to the flows and the refresh token request as well. This way, client can obtain refresh tokens with broad scope and narrow down it for particular request (least privileges principle) regards, Torsten. Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav: Proposal: '

Re: [OAUTH-WG] 'Scope' parameter proposal

Am 20.04.2010 05:06, schrieb Dick Hardt: On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote: 2. Server requires authentication HTTP/1.1 401 Unauthorized WWW-Authenticate: Token realm='Example', scope='x2' Can more than one scope be returned? Is it a comma delimited list? I

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, April 19, 2010 4:37 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > On Mon, Apr 19, 2010 at 2

Re: [OAUTH-WG] 'Scope' parameter proposal

>HTTP/1.1 401 Unauthorized >WWW-Authenticate: Token realm='Example', scope='x2' I assume the WWW-Authenticate response header also has an "authz-uri" parameter. WWW-Authenticate: Token realm='Example', scope='x2', authz-uri="https://as.example.com/"; The first time a client app get

Re: [OAUTH-WG] 'Scope' parameter proposal

On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote: > 2. Server requires authentication > >HTTP/1.1 401 Unauthorized >WWW-Authenticate: Token realm='Example', scope='x2' Can more than one scope be returned? Is it a comma delimited list? I wonder how much value this will provide. (I like

Re: [OAUTH-WG] 'Scope' parameter proposal

On Mon, Apr 19, 2010 at 2:20 PM, Eran Hammer-Lahav wrote: > >> -Original Message- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Monday, April 19, 2010 1:50 PM > >> I did a proof of concept implementation, with client, server and protected >> resource support libraries,

Re: [OAUTH-WG] 'Scope' parameter proposal

On Apr 19, 2010, at 6:17 PM, Eran Hammer-Lahav wrote: [...] >>> >> >> I think that there is much that is unspecified in this model and thus it >> doesn't >> provide much interoperability. If we don't tell the client what to do with >> the >> scope, and we don't specify what a server means by

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: John Kemp [mailto:j...@jkemp.net] > Sent: Monday, April 19, 2010 2:59 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrot

Re: [OAUTH-WG] 'Scope' parameter proposal

On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrote: > Proposal: > > 'scope' is defined as a comma-separated list of resource URIs or resource > groups (e.g. contacts, photos). So, 'scope' at the authenticating (via OAuth) server is simply a list of one or more URIs? There are no defined, int

Re: [OAUTH-WG] 'Scope' parameter proposal

+1 Eran's proposal as well On Mon, Apr 19, 2010 at 1:34 PM, Torsten Lodderstedt wrote: > +1 > > Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav: >> >> Proposal: >> >> 'scope' is defined as a comma-separated list of resource URIs or resource >> groups (e.g. contacts, photos). The server can provide

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, April 19, 2010 1:50 PM > How does defining the scope structure help interop? Clients can use scopes the same way across provides and don't need to read paperwork to figure out how to use the pa

Re: [OAUTH-WG] 'Scope' parameter proposal

On Mon, Apr 19, 2010 at 11:14 AM, Eran Hammer-Lahav wrote: > >> -Original Message- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Monday, April 19, 2010 11:04 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG]

Re: [OAUTH-WG] 'Scope' parameter proposal

+1 Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav: Proposal: 'scope' is defined as a comma-separated list of resource URIs or resource groups (e.g. contacts, photos). The server can provide a list of values for the client to use in its documentation, or the client can use the URIs or scope iden

Re: [OAUTH-WG] 'Scope' parameter proposal

> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, April 19, 2010 11:04 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal > > On Mon, Apr 19, 2010 at 9:25 AM, Eran H

Re: [OAUTH-WG] 'Scope' parameter proposal

On Mon, Apr 19, 2010 at 9:25 AM, Eran Hammer-Lahav wrote: > Proposal: > > 'scope' is defined as a comma-separated list of resource URIs or resource > groups (e.g. contacts, photos). How will commas in URIs be escaped? We just forbid them? If the scope elements are URIs then a space separated lis

Re: [OAUTH-WG] 'Scope' parameter proposal

Monday, April 19, 2010 9:25 AM To: OAuth WG Subject: [OAUTH-WG] 'Scope' parameter proposal Proposal: 'scope' is defined as a comma-separated list of resource URIs or resource groups (e.g. contacts, photos). The server can provide a list of values for the client to use in its do

[OAUTH-WG] 'Scope' parameter proposal

Proposal: 'scope' is defined as a comma-separated list of resource URIs or resource groups (e.g. contacts, photos). The server can provide a list of values for the client to use in its documentation, or the client can use the URIs or scope identifier of the protected resources it is trying to acce

Re: [OAUTH-WG] Scope using Realm idea

On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote: That's only when you need to trust the client. If your requirements demand registration, discovery is mostly pointless (other than dynamic configuration). At the risk of comparing apples and pears - many large-scale SAML deployments rely on di

Re: [OAUTH-WG] Scope using Realm idea

Yes, if we go with RFC 2617, then--and please correct me if I am wrong--it looks to me that *realm* here means pretty much the same thing as *Kerberos realm*. I strongly agree on getting the definition clear, and I agree that nothing should be "opaque." (I as puzzled by the quoted exchange, an

Re: [OAUTH-WG] Scope using Realm idea

On Tue, Apr 6, 2010 at 3:12 PM, Eran Hammer-Lahav wrote: > I am still waiting for someone to show how a scope parameter with an opaque > value helps interop, where every single example requires the client to know > how to construct this opaque string. OAuth libraries will need to support > extensi

Re: [OAUTH-WG] Scope using Realm idea

Thanks John. I tend to agree that realm comes with a lot of baggage and is probably not going to work given people's expectations. After all, they are not likely to study 2617 before implementing OAuth. The point of my proposal was to show one aspect of scope in which the client is being told

Re: [OAUTH-WG] Scope using Realm idea

I am still waiting for someone to show how a scope parameter with an opaque value helps interop, where every single example requires the client to know how to construct this opaque string. OAuth libraries will need to support extension parameters - that's a given. So how is this not an extension

Re: [OAUTH-WG] Scope using Realm idea

On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wrote: > The question is how your APIs are structure. Do you have APIs that require > multiple “scopes” in a single call? Things can get even more complicated. When the user grants access for the client, the approval page should list all the scope

Re: [OAUTH-WG] Scope using Realm idea

That's only when you need to trust the client. If your requirements demand registration, discovery is mostly pointless (other than dynamic configuration). EHL On 4/6/10 6:58 AM, "Brian Eaton" wrote: Web clients are expected to have secrets or to have otherwise registered with the AS. In orde

Re: [OAUTH-WG] Scope using Realm idea

The question is how your APIs are structure. Do you have APIs that require multiple "scopes" in a single call? EHL On 4/6/10 8:29 AM, "Luke Shepard" wrote: For Facebook at least, we are currently planning to use scope as a comma-separated list of permissions from this set: http://wiki.devel

  1   2   >