Thanks Dick! This is incredibly useful. I'll apply all the comments to the spec
tomorrow before pushing it as -00 (pending chairs approval).
I'll reply to the (very few) comments I didn't agree/understand once I have a
new draft.
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Sunday
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Sunday, April 18, 2010 1:38 PM
> Also, when implementing OAuth 2.0 people will take into account existing
> parameters and will avoid them, they will chose other parameter names (if
> possible). If the n
I'm strongly opposed to writing a spec that must be profiled in order to be
implemented and the proposed definition of the scope parameter mandates
profiling the spec.
If it has a structure - what is it? If it is an opaque string, where does the
client get it from? You cannot have interop if th
On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Dick Hardt
>> Sent: Sunday, April 18, 2010 9:20 PM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Issue: state in web server flow
>>
>>
The spec should describe how the redirect URI is verified to what is
registered. I can enumerate the options for discussion adding in the state
parameter as an option.
On 2010-04-18, at 10:16 PM, Eran Hammer-Lahav wrote:
> This is where limiting variations to a client state parameter helps, but
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Dick Hardt
> Sent: Sunday, April 18, 2010 9:20 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue: state in web server flow
>
> Why was the state parameter removed from the web server flow?
I d
On 2010-04-18, at 9:56 PM, Eran Hammer-Lahav wrote:
> The client_id parameter is not expected to have an internal structure known
> to clients.
The client developer needs to understand it.
> The likelihood of a client library treating this value as anything other than
> an opaque string is p
+1 to #1
On 2010-04-18, at 9:35 PM, Luke Shepard wrote:
>
> 1/ We leave the scope parameter as an Auth Server-specific, opaque parameter.
> 2/ We all agree on a format and spec for the scope parameter.
> 3/ We drop the scope parameter and make each server define their own,
> non-standard scope pa
Noted. I'll tweak the text to accommodate this scenario. Note that 'the
authorization server MUST retain the scope' is met if the scope is encoded into
the token and later verified when used. It doesn't say how the scope must be
retained. But I see your point.
EHL
From: oauth-boun...@ietf.org
This is where limiting variations to a client state parameter helps, but
consensus was that we cannot limit clients not to use local query parameters
outside the state.
The problem with giving specific guidance is that it can open security holes.
For example, not checking the value of a query p
Every format requires some encoding, and if we limit the character set we will
just be pushing the problem elsewhere (forcing servers to encode or define
encoding for clients). Right now the assumption is that developers will
implement the format (form-encoded) correctly, which will take care of
Scheme is always case-insensitive per 2617.
My reasons for using Token:
1. The scheme isn't specific to OAuth (which defines a model for obtaining
tokens). It is a generic way to use tokens for authentication. Similar to how
services use OAuth today for "2-legged" authentication (using the sign
The client_id parameter is not expected to have an internal structure known to
clients. The likelihood of a client library treating this value as anything
other than an opaque string is practically zero. client_id is well defined,
especially when it comes to how clients are expected to interact
David Recordon wrote:
>> Does anyone have an implementation example where comma separated
>> strings wouldn't work for the scope parameter?
Marius wrote:
> Yes, Google currently is using a space separated list of URIs.
> Why does the format matter?
I agree. Facebook uses comma-separate strings,
I recall some earlier discussion on calling the scheme Token vs OAuth and see
that it is now Token per the example:
Authorization: Token token="vF9dft4qmT"
Would explain or point out the logic of using Token rather than OAuth?
A related question: is the scheme case sensitive?__
The AS token endpoint response is encoded as application/x-www-form-urlencoded
While this reuses a well known and understood encoding standard, it is uncommon
for a client to receive a message encoded like this. Most server responses are
encoded as XML or JSON. Libraries are NOT reedily availabl
Some AS will match part of the URI to what was registered, some require
everything up to the start of a query. The spec needs to clarify how much of
the URI needs to be matched, or state it is AS specified.
-- Dick
___
OAuth mailing list
OAuth@ietf.org
Why was the state parameter removed from the web server flow?
Some AS may require the entire redirect URI to be registered, so the state
parameter allows a client to maintain state across calls.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
On Sun, Apr 18, 2010 at 7:04 PM, David Recordon wrote:
> Does anyone have an implementation example where comma separated
> strings wouldn't work for the scope parameter?
Yes, Google currently is using a space separated list of URIs.
Why does the format matter?
Marius
>
>
> On Sun, Apr 18, 201
On 2010-04-18, at 9:04 PM, Marius Scurtescu wrote:
> On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt wrote:
>> Since calls to the token endpoint use POST, there can not be any confusion
>> between the parameters in the body of the message and URI query parameters
>
> Unfortunately in the Java world
On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt wrote:
> Since calls to the token endpoint use POST, there can not be any confusion
> between the parameters in the body of the message and URI query parameters
Unfortunately in the Java world there is confusion between POST and
GET parameters. The serv
General comments:
Putting the flow description, diagram and steps in the section with the spec
work well.
Use of "server" term. In numerous places, the term server is used instead of
authorization server or resource server (maybe even web server). To avoid
ambiguity, I would suggest the term s
The spec describes the access token as an identifier. One of the key
capabilities of WRAP was that the token could be self contained. The PR could
make an access control decision by examining the access token and not calling
the AS.
The token is referred to as an identifier in the Abstract, In
Does anyone have an implementation example where comma separated
strings wouldn't work for the scope parameter?
On Sun, Apr 18, 2010 at 6:47 PM, Dick Hardt wrote:
> I would leave that to be AS defined -- different delimiters make sense in
> different environments -- it could be an expression --
I'm happy to hear that Facebook engineers are enjoying their job.
In choosing between long and ambiguous, I think we need to choose long. We
could shorten the prefix to oa_. Would that help? :)
On 2010-04-18, at 6:42 PM, David Recordon wrote:
> While Facebook platform engineers were quite dubi
I would leave that to be AS defined -- different delimiters make sense in
different environments -- it could be an expression -- just make it a string --
it will need to be URL encoded which will deal with any magic characters.
-- Diok
On 2010-04-18, at 6:38 PM, David Recordon wrote:
> I thin
While Facebook platform engineers were quite dubios of no oauth_
prefix after hacking on a draft implementation their opinion has
changed. They're now really enjoying shorter and cleaner paramater
names and found them to be easier to document and no more difficult to
implement.
On Sun, Apr 18, 20
I think we need to add a bit more definition to the scope parameter.
Maybe as simple as a comma-separated list of strings.
On Sun, Apr 18, 2010 at 6:12 PM, Dick Hardt wrote:
> The scope parameter was included in WRAP at the request of library and AS
> implementors to standardize a commonly inclu
The scope parameter was included in WRAP at the request of library and AS
implementors to standardize a commonly included parameters.
The client_id parameter seems similar to the scope parameter. The meaning of
client_id is not defined in the spec and is AS specific. A client_id that a
developer u
(restarting discussion from
http://groups.google.com/group/oauth-ietf-wg/browse_thread/thread/8aeb31817ead4c2a/f19773643e0a8ba3?pli=1
with matching subject)
Given the practice that the authorization endpoint and the redirect_uri can
contain URI query parameters, then differentiating bet
All,
Can the 'Token' Authorization scheme also be used by HTTP proxies? i.e.
similar to the WWW-Authenticate header, a proxy might use the
Proxy-Authenticate header to require a token. This might be useful in
enterprise scenario's, for example
Regards,
Jeroen
On Fri, Apr 16, 2010 at 6:23 PM, Luke Shepard wrote:
> So, I originally favored the prefix, as I couldn’t see how you would not do
> it.
>
>
>
> But I’ve recently implemented OAuth prototype and written some apps against
> it, and I have to say, I like not having the prefix. Most developers don’t
On Fri, Apr 16, 2010 at 6:08 PM, Eran Hammer-Lahav wrote:
> We are going in circles. We are just not going to agree on this.
>
> I don’t think we should have a parameter prefix for OAuth-specific calls,
> you think we should. Time to let other people express their view on this.
> I’m sure both of
from my point of view, the discussion is not necessarily about other
means (== authn mechn). Shared secrets are acceptable for most cases.
The discussion is about how client credentials are passed to the
authorization server API (direct calls only). The proposal is to do it
the HTTP authenticat
34 matches
Mail list logo
