On Tue, Jun 14, 2011 at 10:00 PM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Manger, James H
>> Sent: Tuesday, June 14, 2011 7:06 PM
>> To: oauth
>> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as
This whole cookie thing is a 'a bit hacky'... that's part of what we're working
with... :-)
EHL
> -Original Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Tuesday, June 14, 2011 10:39 PM
> To: Eran Hammer-Lahav; oauth
> Subject: RE: [OAUTH-WG] FW: MAC:
>> How does the server know if a particular request with a "Authorization: MAC
>> ..." header is using credentials from OAuth 2.0 or from Set-Cookie?
> This should be pretty easy to resolve with a common-sense deployment and key
> identifiers.
You are right, Eran. Though putting a cookie-name in
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Tuesday, June 14, 2011 7:06 PM
> To: oauth
> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>
> >>> Perhaps omitting the id parameter from the A
>>> Perhaps omitting the id parameter from the Authorization header
>>> would be an even better approach [when a cookie provides the key id]
>> Yeah, I've often wondered whether we should remove the id parameter
>> from the Authorization header. My understanding is that it plays some
>> important
Bearer token doesn't exist within the core spec around getting an
access token. The term that is used is "access token".
On Tue, Jun 14, 2011 at 8:12 AM, Bill wrote:
> On 10/06/11 17:45, David Recordon wrote:
>>
>> I think it's vital to have the GET and POST parameters make sense to
>> every dev
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Adam Barth
> Sent: Tuesday, June 14, 2011 10:05 AM
> To: Manger, James H
> Cc: oauth
> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>
> On Tue, Jun 14, 2011 at 7:25 A
The Web Authorization Protocol Working Group (oauth) in the Security
Area of the IETF has been rechartered. For additional information,
please contact the Area Directors or the working group Chairs.
Web Authorization Protocol Working Group (oauth)
---
Current Status: Active
On Tue, Jun 14, 2011 at 7:25 AM, Manger, James H
wrote:
>>> There have been suggestions that the MAC calculation could/should cover
>>> the key id. In that situation it is even more crucial that the id field
>>> isn't just a
>>> name referring to the real value elsewhere - as then the security ch
On 10/06/11 17:45, David Recordon wrote:
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.
I agree with David regardless of engineering strengt
>> There have been suggestions that the MAC calculation could/should cover
>> the key id. In that situation it is even more crucial that the id field
>> isn't just a
>> name referring to the real value elsewhere - as then the security changes
>> based on the syntax used to issue the credentials.
On 14/06/11 06:20, Barry Leiba wrote:
> The charter that we discussed here was sent out for internal review on
> 31 May, and was approved by the IESG last Thursday -- that should be
> officially announced any time now. That charter, if you recall, was
> very focused and included milestones for s
On Mon, Jun 13, 2011 at 7:17 PM, Manger, James H
wrote:
>>> This is a bit hacky, too hacky. Wouldn't it be better for a client that
>>> recognizes a special MAC cookie to use it to construct Authorization headers
>>> and omit it from Cookie headers?
>
>> Nope. Sending the value in the Cookie head
13 matches
Mail list logo
