Re: [OAUTH-WG] Indicating sites where a token is valid

Evan, > The key point is that this discovery covers a lot of the same grounds as the > sites parameter, and it's hard to define semantics around a sites parameter > without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is

Re: [OAUTH-WG] Indicating sites where a token is valid

Thanks for the response - feedback inline... On Wed, May 12, 2010 at 5:09 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Evan, > > > 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

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

On Mon, May 10, 2010 at 7:53 PM, Eran Hammer-Lahav wrote: > Propose text. Tried to write some text, but still not sure what the right solution is. redirect_uri matching is done in two flows: Web Server and User-Agent. In Web Server the matching issue can be avoided by always requiring redirect_

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote: > >> >> Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff >> grouped into one document. There seems to be consensus to do that, but it >> still runs counter to the conventional wisdom. > > Can you point to specific

Re: [OAUTH-WG] Indicating sites where a token is valid

Evan, > 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 ans

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

> -Original Message- > From: Robert Sayre [mailto:say...@gmail.com] > Sent: Wednesday, May 12, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Prateek Mishra; oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav wrote: > > And this is truly *not* aimed at anyone in particular: I'm getting tired of > people lecturing the group about what makes a good standard. Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff grouped into one doc

Re: [OAUTH-WG] Indicating sites where a token is valid

On Mon, May 10, 2010 at 4:30 PM, Evan Gilbert 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 re

Re: [OAUTH-WG] Provisional OAuth enhancements

OK, just started this experiment :) - Added a section on the OAuth IETF Wiki for proposed enhancements: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2ProvisionalEnhancements. - First proposal is for "username" parameter: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. I

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

The spec should only directly enable extensibility where extensibility is a requirement/use case. For example, we know we are going to have more flows, so the spec should define the process to add new flows and register their 'type' value. Same with other HMAC algorithms. However, making someth

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

Eran, I want to support the idea of a minimal specification, that supports the basic use-case with no frills. Successful standards are usually small and with strong focus on a few key use-cases But the specification does need to point to or document some extensibilty points. Otherwise, imple

Re: [OAUTH-WG] Strict equality matching of redirect_uri

If I understand correctly, Twitter does strict matching (against a list) and Facebook does prefix matching. If I am a client and want to integrate with Facebook only, I may take advantage of the prefix matching and rely on that. What if at some point in the future I now want to integrate with Twi

Re: [OAUTH-WG] sites with wildcard

On Tue, May 11, 2010 at 5:37 PM, Manger, James H wrote: > Marius, > >>> Should it send the token when getting the photos? > >> I would say definitely not. If the client gets back a 403 with >> discovery info that points to the same authz server and approved >> scopes, only then could the client re

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

There is a bit of confusion here. We had clear consensus that the client credentials are only used to obtain a token, not to access protected resources. Some flows use just the client identifier, while others use both the identifier and shared secret. The assertion flow doesn't use it at all.

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

But client_secret is not defined specific to a given flow - its used by the web server, user name, and client credentials flows. I can find no mention of the client using the client_secret for crypto authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to clients authenti

Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

I challenge the claim that the spec gets harder to read. In fact the spec becomes cleaner if we move from one special case to a general description. Implementing other authn schemes while keeping the spec hardwired to shared-secrets might be trivial but those implementations will always be hacks.