Eran said:
> Why is a version better than a new scheme name?
YAY!
Using a new scheme name if/when we aren't using a bearer token is a great idea.
Today OAuth2 only defines how to access a protected resource with a bearer
token [the "Token" scheme in section 5]. Assume this is standardized soon,
On 2010-07-01, at 12:52 PM, Naitik Shah wrote:
> Searching for base64url does make it better. Thanks for that pointer Dick.
>
> We don't think base64url will work, because the most common error we'll see
> is that developers forget the "url" part and just do plain base64, and that's
> not suff
I was wondering if there are any other government employees on this list who
may be looking to leverage the OAuth Protocol in their applications.
We are leveraging OAuth 2.0 (rev05) server / client it in an internal
prototype we are working on and wanted to reach out to other government
employees
On Thu, Jul 1, 2010 at 4:21 PM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, July 01, 2010 2:59 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] register prefixes as opposed to full para
Good point. No error required.
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Thursday, July 01, 2010 3:05 PM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Support for query/body param
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 2:59 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter
> names
>
> On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lah
Sounds good. Please submit a draft and we can discuss incorporating it into
core later.
As for discovery, I plan to support both super-light header discovery and a
richer host-meta/XRD based discovery. As we discuss it, we will decide if we
need the heavier one.
EHL
From: Torsten Lodderstedt
you are right. So the only trustworthy way to enter credentials is an
external browser?
regards,
Torsten.
Am 28.06.2010 20:11, schrieb Marius Scurtescu:
On Fri, Jun 25, 2010 at 10:33 PM, Torsten Lodderstedt
wrote:
comment/question regarding the Embedded Browser scenario: Is the URL bar
ok sounds good. But AFAIK "authentication required" is already the
meaning of status code 401. So why another error parameter?
regards,
Torsten.
Am 01.07.2010 23:54, schrieb Eran Hammer-Lahav:
That's where the error parameter will be (the only supported place in -09 for a
failed protected res
On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, July 01, 2010 2:21 PM
>
>> >> 2. Greatly reduce the chances of a conflict with a query parameter
>> >> used by an authz server endpoi
since the rewrite of the draft the token endpoint has become a token
issuing endpoint, so revocation does not really fit into the picture. We
could add another endpoint for the purpose. This endpoint should support
both token types. Authorization server should be given the option to
decide for
That's where the error parameter will be (the only supported place in -09 for a
failed protected resource response).
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Thursday, July 01, 2010 2:51 PM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtesc
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 2:21 PM
> >> 2. Greatly reduce the chances of a conflict with a query parameter
> >> used by an authz server endpoint or client redirect_uri.
> >
> > There should not be any confl
I essentially agreed, except in 3. the server should send back status
code 401 with a WWW-Authenticate header.
regards,
Torsten.
Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav:
I think all servers must support the header. I don't think we can demand all
servers to support query or post parame
I'm also fine with a note in the spec that says, something like "If you
need to support 1.0a and 2 on the same protected resource it is
RECOMMENDED that you always use the Authorization header variant."
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
>
In re:
1. Token syntax
2. Presence of 'oauth_signature_method'
3. Presence of 'oauth_signature'
4. Presence of no other 'oauth_' parameter than 'oauth_token'
We can certainly do better than this. Yeah, the server should be smart
enough, but this seems unneccesary
[Replying to everything at once...]
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 11:36 AM
> Not sure about the future, but looking at OAuth 1 vs OAuth 2. A protected
> resource request filter may want to decide early what pro
I think that works.
POST body support can even be moved to a separate spec, if anyone
really uses it.
Marius
On Thu, Jul 1, 2010 at 1:28 PM, Eran Hammer-Lahav wrote:
> I think all servers must support the header. I don't think we can demand all
> servers to support query or post parameters a
On Thu, Jul 1, 2010 at 1:35 PM, Eran Hammer-Lahav wrote:
> I don't think this is necessary.
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Marius Scurtescu
>> Sent: Thursday, July 01, 2010 12:52 PM
>> To: OAuth WG
>> Subject: [OAUTH-
So does this mean that supporting multiple protocols ends is in conflict
with allowing use of POST parameters?
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Eran Hammer-Lahav
> Sent: Thursday, July 01, 2010 1:28 PM
> To: Marius Scurtes
I don't think this is necessary.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:52 PM
> To: OAuth WG
> Subject: [OAUTH-WG] register prefixes as opposed to full parameter names
>
> For s
I think all servers must support the header. I don't think we can demand all
servers to support query or post parameters as that can conflict with their
existing namespace or architecture. I suggest we:
1. Make the "Token" scheme required in all resource servers
2. Allow resource servers to supp
The rest of the parameters being in the body.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:26 PM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Versioning
>
>
Searching for base64url does make it better. Thanks for that pointer Dick.
We don't think base64url will work, because the most common error we'll see
is that developers forget the "url" part and just do plain base64, and
that's not sufficient because the stock set includes +.
So it will maybe wo
For section 6.2, and possibly 6.3, I would suggest to register a
prefix for all the parameters defined by an extension.
Pros:
1. Simpler registration, only one element needs to be registered, the
prefix, and not every single parameter name. Once an extension has a
prefix registered it can evolve
On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote:
>> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
>>
>> Just curious. What use case would require that the access token is put
>> in the post body as opposed to an http header when accessing a
>> protected resource?
>
>
> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
>
> Just curious. What use case would require that the access token is put
> in the post body as opposed to an http header when accessing a
> protected resource?
If nothing else, it parallels the use case of a GET-style quer
With this the spec needs to including some wording to explicitly define
how to handle the case when running an endpoint supporting both OAuth
1.0 and 2.0 and the oauth2_token is missing then the call is handled
according to the OAuth 1.0/a spec. Whatever is decided, be it a version
parameter, t
On Thu, Jul 1, 2010 at 12:07 PM, Justin Richer wrote:
> OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
Just curious. What use case would require that the access token is put
in the post body as opposed to an http header when accessing a
protected resource?
Marius
__
OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
-- Justin
On Thu, 2010-07-01 at 14:47 -0400, Marius Scurtescu wrote:
> On Thu, Jul 1, 2010 at 11:42 AM, William Mills wrote:
> >
> >
> >> -Original Message-
> >> From: Marius Scurtescu [mailto:mscurte...@google.com]
>
An easy fix here is to use oauth2_token instead of oauth_token here,
since that's the only place we seem to be using the oauth_ namespace
now. Makes figuring out the two completely deterministic since it's a
different parameter name when passed as a GET or POST variable, and a
different header name
Perhaps it's enough if in the spec we make clear that we are also defining a
scheme usable for other things. I don't think that's quite spelled out. Then
other specs just refer to the specific section like we're pulling in the
WWW-Authenticate part from another spec.
> -Original Message-
On Thu, Jul 1, 2010 at 11:42 AM, William Mills wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, July 01, 2010 11:36 AM
>> To: Eran Hammer-Lahav
>> Cc: William Mills; Rob Richards; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Versioni
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 11:36 AM
> To: Eran Hammer-Lahav
> Cc: William Mills; Rob Richards; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Versioning
>
> On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav
>
Eran Hammer-Lahav wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 10:37 AM
To: Eran Hammer-Lahav
Cc: Rob Richards; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning
On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lah
It was and this approach was rejected by this group as confusing. At this
point, it's specification is so short, it can live anywhere.
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 11:28 AM
> To: Eran Hammer-Lahav
> Cc: W
On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav wrote:
>
> If you would like to discuss a version for the header, please provide
> examples and requirements for what changes in the future you would like to
> support.
Not sure about the future, but looking at OAuth 1 vs OAuth 2. A
protected r
> > In most instances outside of the Big Web Companies, OAuth is going to be
> > the new kid being grafted onto an existing framework or application. As
> > such, it really needs to play nice.
>
> Just a side note, with extensions also being simple names added to the
> protocol chances of a collis
On Thu, Jul 1, 2010 at 11:19 AM, Eran Hammer-Lahav wrote:
> I think HTTP authentication schemes should be generally useful. In this case,
> OAuth defines a few ways to obtain an token, and a few ways to use a token
> with HTTP resources. What it doesn't do is say anything useful about the
> tok
+1 on this. Makes life interesting on the PR.
> When tokens are passed in the query string there is no scheme.
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 11:16 AM
> To: Eran Hammer-Lahav
> Cc: William Mills; Rob Richards
The 1.0 install base is small enough to ignore. Looking at the interest and
community around 2.0 makes such considerations marginal.
There is no problem with underscores in headers, it is just unusual.
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Se
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 11:16 AM
> To: Eran Hammer-Lahav
> Cc: William Mills; Rob Richards; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Versioning
>
> On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav
> w
3 - all underscores.
If underscores are a big issue with headers then we should consider 1
- all dashes. The problem with all dashes is that it is
counterintuitive for people that know OAuth 1.
Marius
On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
I think HTTP authentication schemes should be generally useful. In this case,
OAuth defines a few ways to obtain an token, and a few ways to use a token with
HTTP resources. What it doesn't do is say anything useful about the token
itself, or implies that the tokens are "OAuth tokens" (i.e. that
On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav wrote:
> Why is a version better than a new scheme name?
Sure, but then make the scheme more specific. What will the scheme
name be for OAuth 3?
When tokens are passed in the query string there is no scheme.
Marius
>
> EHL
>
>> -Original M
Why is using the string "Token" better than "OAuth2"? 1.0 used "Oauth".
If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token"
because I feel it's clearer and more descriptive.
> -Original Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Thursday
Don't really care, but to pick one - underscores throughout.
Why not headers?
On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote:
> That's wasn't an option for a reason. Beside offending my esthetic
> sensibility :-) having the same parameter use a different name between the
> header and endp
I was told that my last paragraph was greatly insulting. I want to apologize if
it came off that way or if anyone perceived it as directed at them. I think the
quality of the discussion about version for the past year has been of low
quality. People did not present requirements or shows an actua
On Thu, Jul 1, 2010 at 6:03 AM, Justin Richer wrote:
> #2 is the best route forward. If a particular extension requires its
> parameters to be present and handled, then it has a few different
> options. One is breaking at the server side, either with an explicit
> error or throwing away some other
> -Original Message-
> From: Luke Shepard [mailto:lshep...@facebook.com]
> Sent: Thursday, July 01, 2010 10:58 AM
> To: Eran Hammer-Lahav
> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
>
> Don't really care, but to
Why is a version better than a new scheme name? Version is only helpful when
the protocol is practically the same with some minor changes, and if that is
the case, extensibility alone should be enough.
EHL
> -Original Message-
> From: William Mills [mailto:wmi...@yahoo-inc.com]
> Sent:
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Thursday, July 01, 2010 10:37 AM
> To: Eran Hammer-Lahav
> Cc: Rob Richards; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Versioning
>
> On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav
> wrote:
+1
> I don't think the authz server endpoints are an issue, but
> the protected resources. The auth scheme is very generic,
> "Token". So either the scheme should be more specific, like
> "OAuth2", or a version should be added as a parameter. Maybe
> a token type as Dick suggested.
> -Or
My feeling on this is that versioning explicitly in the protocol adds
clarity and some small level of compatibility. Different auth and token
endpoints are easy, what's harder is supporting multiple protocols on
the same protected resource. It's on the protected resource I'd like to
see some clea
On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav wrote:
> Hi Rob,
>
>> -Original Message-
>> From: Rob Richards [mailto:rricha...@cdatazone.org]
>> Sent: Thursday, July 01, 2010 3:26 AM
>> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
>> Subject: Versioning
>>
>> Versioning is still so
Ignore as in, pretend it wasn't sent (from either the client or server).
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Thursday, July 01, 2010 6:03 AM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG
> Subject: Re: [OAUTH-WG] How do we deal with unr
Hi Rob,
> -Original Message-
> From: Rob Richards [mailto:rricha...@cdatazone.org]
> Sent: Thursday, July 01, 2010 3:26 AM
> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
> Subject: Versioning
>
> Versioning is still something that needs to be addressed before being being
> able to con
That's wasn't an option for a reason. Beside offending my esthetic sensibility
:-) having the same parameter use a different name between the header and
endpoint makes registration of extension parameters much harder. For example,
if we used this scheme, the 'error-uri' parameter would require t
+1 for underscores except header keys.
-- Justin Hart
-- jh...@photobucket.com
On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote:
> I already implemented 09 but it was a (very tiny) bit of a hassle to
> have to convert underscores.
>
> So I also agree with 3 except headers
>
> On Th
#2 makes most sense to me
On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer wrote:
> #2 is the best route forward. If a particular extension requires its
> parameters to be present and handled, then it has a few different
> options. One is breaking at the server side, either with an explicit
> error
I already implemented 09 but it was a (very tiny) bit of a hassle to
have to convert underscores.
So I also agree with 3 except headers
On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock
wrote:
> 3 except headers.
>
> 2010/7/1 Eran Hammer-Lahav :
>> First, sorry about this. J
>>
>>
>>
>> I do my
#2 is the best route forward. If a particular extension requires its
parameters to be present and handled, then it has a few different
options. One is breaking at the server side, either with an explicit
error or throwing away some other required bit, which has been
mentioned. Another is looking fo
Versioning is still something that needs to be addressed before being
being able to consider the draft core complete.
On this I'm still of the opinion that at the very minimum you will need
to require an oauth_version parameter for the resource endpoints, if not
also for the others as well.
Ro
63 matches
Mail list logo
