On Fri, Jun 10, 2011 at 3:19 PM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: Robert Sayre [mailto:say...@gmail.com]
>> Sent: Friday, June 10, 2011 11:37 AM
>> To: Adam Barth
>> Cc: Eran Hammer-Lahav; OAuth WG
>> Subject: Re: Why not use a server-supplied nonce (was: HTTP MAC
>>
> -Original Message-
> From: Robert Sayre [mailto:say...@gmail.com]
> Sent: Friday, June 10, 2011 11:37 AM
> To: Adam Barth
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: Why not use a server-supplied nonce (was: HTTP MAC
> Authentication Scheme)
>
> On Fri, Jun 10, 2011 at 10:51 AM, A
Extensibility in authentication schemes is a bad thing, given how they are
deployed and the difficulty of changing them. No existing authentication scheme
is extensible (explicitly).
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of M
Nico,
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones
> wrote:
> > What issues, specifically. (Messages are all over the place and I
> > don’t know exactly what issues you’re raising. Is it with the
> > approach we’re proposing or something else?)
>
> The fundamental issue is that protecting
On Fri, Jun 10, 2011 at 2:16 PM, Adam Barth wrote:
> On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams wrote:
>> The fundamental issue is that protecting the cookie alone is not
>> enough. On open wifi networks it's a fair assumption that the
>> difficulty of active attacks is about the same as th
On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams wrote:
> [Dropped a few lists.]
>
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrote:
>> What issues, specifically. (Messages are all over the place and I don’t
>> know exactly what issues you’re raising. Is it with the approach we’re
>> propo
Shane,
We have been working on openID Connect (formerly known as openID AB) for some
time.
If there are standard ways to do things in OAuth 2.0 that we can reuse then it
saves us from inventing custom extensions for openID Connect.
We have identified the need to request multiple tokens as one
On Fri, Jun 10, 2011 at 11:36 AM, Robert Sayre wrote:
> On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth wrote:
>> On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre wrote:
>>> Let's call my proposed addition the "opaque" parameter. The client
>>> sends it back unchanged, just like the id.
>>
>> That al
On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth wrote:
> On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre wrote:
>> Let's call my proposed addition the "opaque" parameter. The client
>> sends it back unchanged, just like the id.
>
> That already exists in the scheme. It's just the value of the cookie
On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre wrote:
> Let's call my proposed addition the "opaque" parameter. The client
> sends it back unchanged, just like the id.
That already exists in the scheme. It's just the value of the cookie.
> This is just one use of an opaque field that servers mi
On Thu, Jun 9, 2011 at 10:25 PM, Adam Barth wrote:
>
> What happens when the client wants to send more than one request at a
> time to the server? For example, when loading a web page, browsers
> often open multiple sockets to send multiple request in parallel to
> improve performance.
In my exa
On Fri, Jun 10, 2011 at 9:34 AM, John Kemp wrote:
> George,
>
> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>
>> I definitely don't want to change the Authorization header naming scheme. I
>> believe it should stay 'Bearer' because that's what the token is. We could
>> make it...
>>
>> A
[Dropped a few lists.]
On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrote:
> What issues, specifically. (Messages are all over the place and I don’t
> know exactly what issues you’re raising. Is it with the approach we’re
> proposing or something else?)
The fundamental issue is that protecti
I think it's vital to have the GET and POST parameters make sense to
every developer. I worry less about the authorization header since a
developer implementing it will honestly be a stronger engineer.
Here's what I said earlier in the thread about my motivation:
> Did a full read through of draft
Don't care. Will never use it. :-)
EHL
> -Original Message-
> From: David Recordon [mailto:record...@gmail.com]
> Sent: Friday, June 10, 2011 1:20 AM
> To: George Fletcher; Eran Hammer-Lahav; Doug Tangren
> Cc: Mike Jones; paul Tarjan; oauth@ietf.org; Marius Scurtescu
> Subject: Re: [OAUT
George,
On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
> I definitely don't want to change the Authorization header naming scheme. I
> believe it should stay 'Bearer' because that's what the token is. We could
> make it...
>
> Authorization: Bearer access_token=vF9dft4qmT
>
> If that hel
+1 :)
On 6/10/11 9:23 AM, Doug Tangren wrote:
I hope hope that if it changes again this time, it doesn't change
again :)!
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-Doug Tangren
http://lessis.me
On Fri, Jun 10, 2011 at 4:20 AM, David Recordon wrote:
> George, Doug and Eran are you alright with the Bearer token spec using
> the parameter name "access_token" as well?
>
>
Consistency is good and less confusing for developers writing generic client
libraries.
I definitely don't want to change the Authorization header naming
scheme. I believe it should stay 'Bearer' because that's what the token
is. We could make it...
Authorization: Bearer access_token=vF9dft4qmT
If that helps with consistency. I don't think we should be associating
the term 'acce
What does this mean for the HTTP Authorization header naming scheme for bearer
tokens?
As I understand this decision, we are discussing whether to standardize on the
name "access_token" when a bearer token is sent as either a URL query
parameter, or in a form POSTed body?
Currently the HTTP A
Yes, that's fine with me.
Thanks,
George
On 6/10/11 4:20 AM, David Recordon wrote:
George, Doug and Eran are you alright with the Bearer token spec using
the parameter name "access_token" as well?
On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu wrote:
On Wed, Jun 1, 2011 at 1:14 PM, Mike J
George, Doug and Eran are you alright with the Bearer token spec using
the parameter name "access_token" as well?
On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu wrote:
> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones
> wrote:
>> If you can drive a consensus decision for the name "access_token",
22 matches
Mail list logo
