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.
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
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.
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
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
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
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
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
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
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
> -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
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
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
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_
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
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
16 matches
Mail list logo
