On 2011-10-12 02:06, Manger, James H wrote:
> 2. The ABNF for does not comply with RFC 2617 "HTTP
Authentication".
So where are we on this? Any progress?
Some progress.
draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...”
request header to match draft-ietf-httpbis-p7-auth
Draft 09 allows either b64token or auth-params. Unless there's a working group
consensus that this must change, both syntax options will be supported.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Ju
On 2011-10-12 16:32, Mike Jones wrote:
Draft 09 allows either b64token or auth-params. Unless there's a working group
consensus that this must change, both syntax options will be supported.
-- Mike
...
Mike,
that doesn't work. The restriction in HTTPbis is th
The syntax in HTTPbis is:
credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
The syntax in Bearer 09 is:
credentials = "Bearer" 1*SP ( b64token / #auth-param )
As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and Bearer
are both fine as-is.
On 2011-10-12 20:02, Mike Jones wrote:
The syntax in HTTPbis is:
credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
The syntax in Bearer 09 is:
credentials = "Bearer" 1*SP ( b64token / #auth-param )
As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and Bea
Because b64token is existing practice
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Wednesday, October 12, 2011 11:24 AM
To: Mike Jones
Cc: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
On 2011-10-12
On 2011-10-12 20:26, Mike Jones wrote:
Because b64token is existing practice
> ...
Anyway, how do you then send credentials that include the bearer token
plus additional parameters? Example, please.
Best regards, Julian
___
OAuth mailing list
OAu
One possible syntax is:
Bearer access_token=xyz_-123,more_info=pdq
Ultimately though, the format of the bearer token is outside of the scope of
the spec, and up to the participants to determine, including whether to use
b64token syntax or params syntax.
-- Mike
Not that I will ever use this, but this is really broken way to create a
protocol. Now is the time to make hard choices and pick one format.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Wednesday, October 12, 20
I have suggested before, and I will reiterate that we should define explicitly
how to transport the token in an extensible way if extensions are desired. I
think we shoudl allow both of:
Bearer b64token
and
Bearer token=
The first ensures compatibility with extant implementation,
> One possible syntax is:
>
> Bearer access_token=xyz_-123,more_info=pdq
>
> Ultimately though, the format of the bearer token is outside of the scope of
> the spec, and up to the participants to determine, including whether to use
> b64token syntax or params syntax.
It is great to see an examp
On Wed, Oct 12, 2011 at 5:38 PM, Manger, James H
wrote:
>> One possible syntax is:
>>
>> Bearer access_token=xyz_-123,more_info=pdq
>>
>> Ultimately though, the format of the bearer token is outside of the scope of
>> the spec, and up to the participants to determine, including whether to use
>>
On Oct 12, 2011, at 7:37 PM, Marius Scurtescu wrote:
> While I much prefer what you suggest below (and it was suggested
> before), I think it is too late for that. It will force existing
> deployments to implement ambiguous parsing code.
>
> Let's stick with "Bearer ". If this is the only option,
13 matches
Mail list logo
