On Mon, May 10, 2010 at 4:30 PM, Evan Gilbert <uid...@google.com> wrote:
> I really like the idea behind the "sites" parameter
>
I continue to like the idea behind the "sites" parameter, but think it may
be premature to add to the OAuth spec.
Clients need to know the following in advance:
1. The scope to use to request access to a protected resource
2. The API endpoint to call to access the the protected resource
Solving the question of what URL prefixes are valid to send the token to
seems like it needs to follow answers for #1 and #2 (or at least #2).
As an example, to support #2 we might want to return JSON configuration
about all of the APIs that are available ({'contacts.get': 'http:/...',
'activities.post': 'http://...'}). This would supersede the need for the
sites parameter.
(note: These are the types of issues I'd prefer to start as provisional
enhancements<http://groups.google.com/group/oauth-ietf-wg/browse_thread/thread/f33945621c935c9e>
)
> I think this idea relates closely to scopes and probably needs to be bound
> more tightly to the inbound scope parameter. Both identify a set of
> protected resources that can be accessed with the token - one is the
> requested resources, the other is the granted resources. In both cases you
> need to have a way to find a mapping from protected resource identifier ->
> API endpoint you can call.
>
> On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. <jric...@mitre.org>wrote:
>
>> +1
>>
>> Any information that the client needs to care about should live outside
>> the token.
>>
>> -- Justin
>>
>> ------------------------------
>> *From:* oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
>> Hammer-Lahav [e...@hueniverse.com]
>> *Sent:* Sunday, May 09, 2010 5:29 PM
>> *To:* David Recordon; Marius Scurtescu
>>
>> *Cc:* OAuth WG
>> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid
>>
>> The idea of embedding this information into the token is wrong. This is
>> clearly token metadata and that information belongs alongside the token,
>> just like ‘expires_in’.
>>
>>
>>
>> EHL
>>
>>
>>
>> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
>> Of *David Recordon
>> *Sent:* Friday, May 07, 2010 11:06 AM
>> *To:* Marius Scurtescu
>> *Cc:* OAuth WG
>> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid
>>
>>
>>
>> Using SWT for your access tokens seems like a reasonable way to resolve
>> this for servers which care.
>>
>>
>>
>> On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu <mscurte...@google.com>
>> wrote:
>>
>> Returning a scope parameter with issued tokens is not a bad idea.
>>
>> But this, and also the sites parameter suggested by James, can both
>> potentially be solved with a transparent token format. Such a token
>> can make explicit the:
>> - expiry time
>> - scopes
>> - sites
>> - etc.
>>
>> The Simple Web Token spec goes along these lines. SWT has a parameter
>> called Audience, which I assumed would point to the client, but it
>> could also represent "sites".
>>
>> Marius
>>
>>
>>
>>
>> On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
>> <tors...@lodderstedt.net> wrote:
>> > Additionally, I would propose to indicate the scope associated with a
>> token
>> > to the client using a scope response parameter. This is especially
>> useful
>> > (1) if the client did not pass a scope parameter but the server decided
>> to
>> > associate a scope based on its policy or (2) if the user decided to
>> > authorize a subset of the requested scope only.
>> > Regards,
>> > Torsten.
>> >
>> >
>> >
>> > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
>> > <tors...@lodderstedt.net>:
>> >
>> > what about an additional realm response value?
>> >
>> > If there is a binding between realm and token, the client can decide
>> based
>> > on the realm attribute discovered using a WWW-Authenticate response
>> which
>> > token to use.
>> >
>> > regards,
>> > Torsten.
>> >
>> > Am 07.05.2010 07:06, schrieb Manger, James H:
>> >
>> > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on
>> clients
>> > being told by the server about the sites at which the secret
>> > (cookie/password/token) can be used (and, more importantly, where is
>> must
>> > not be used). This occurs without requiring service-specific knowledge
>> in
>> > the client app. OAuth aims to replace some of these uses.
>> >
>> >
>> >
>> > HTTP Basic authentication works safely from clients with no
>> service-specific
>> > knowledge because the client knows not to send the password it gets from
>> the
>> > user to other sites.
>> >
>> >
>> >
>> > HTTP Digest authentication allows a password to used to across a set of
>> > domains specified in a WWW-Authenticate response header, but the
>> password
>> > will not be used at arbitrary other sites.
>> >
>> >
>> >
>> > Cookies are sent in requests to the same site, sites with the same
>> parent,
>> > or only https sites, depending on details from the service when setting
>> the
>> > cookie.
>> >
>> >
>> >
>> >
>> >
>> > To date, OAuth has assumed every client app has lots of service-specific
>> > knowledge to make these choices. OAuth needs to remove the need for so
>> much
>> > service-specific knowledge to be as interoperable as other standard auth
>> > mechanism, otherwise it is a poor replacement.
>> >
>> >
>> >
>> > --
>> >
>> > James Manger
>> >
>> >
>> >
>> > From: David Recordon [mailto:record...@gmail.com]
>> > Sent: Friday, 7 May 2010 2:05 PM
>> > To: Manger, James H
>> > Cc: OAuth WG
>> > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
>> >
>> >
>> >
>> > Hey James,
>> >
>> > Do you have a specific example in mind where this either has been an
>> issue
>> > or will be an issue? Most client implementations I've seen of OAuth (and
>> > technologies like OAuth) have a strong binding between the access
>> token(s),
>> > site they were issued by, and user they belong to. So I haven't heard of
>> > this being a problem in the wild...
>> >
>> >
>> >
>> > --David
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>> >
>> _______________________________________________
>> 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
