> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, June 13, 2011 6:11 PM
> There have been suggestions that the MAC calculation could/should cover
> the key id. In that situation it is even more crucial that
> I think there has been a confusion. I also thought that the rechartering
> was to be discussed at the July meeting; the IETF call for rechartering was
> issued on May 31.
Right, and that call was not for discussion of rechartering, but for a
review of the specific proposed charter.
The charter
Barry,
I think there has been a confusion. I also thought that the
rechartering was to be discussed at the July meeting; the IETF call for
rechartering was issued on May 31.
My question: has the rechartering discussion been closed in the WG? (If
so, I guess I missed the point when it happe
>> 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 header is important to help
> servers implement this scheme withou
On Sat, Jun 11, 2011 at 3:30 AM, Torsten Lodderstedt
wrote:
> We at Deutsche Telekom have implemented an OAuth 2.0 extension supporting
> that use case. It's called "bulk authorization".
>
> Would that be an interessting topic we could discuss at IETF-81 for the
> re-chartering? I could present o
On Mon, Jun 13, 2011 at 6:11 PM, Manger, James H
wrote:
> A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]:
>
> When MAC credentials are issued with a Set-Cookie response header [section
> 6] the spec says to use the cookie’s name as the MAC key identifier (eg
> “id=SID”). It would mak
A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]:
When MAC credentials are issued with a Set-Cookie response header [section 6]
the spec says to use the cookie's name as the MAC key identifier (eg "id=SID").
It would make more sense to use the cookie's value (eg "id=31d4d96e407aad4
On 6/13/11, Tim wrote:
> Agreed. It is a typical "no one can do it because no one else is
> doing it" situation.
Not quite, as ad networks are free to support TLS. Embedders simply
link to ads using either the http or the https scheme (without
breaking anythings as user agents support both alread
+1
Igor
Torsten Lodderstedt wrote:
Hi,
I also see the need to request and issue multiple tokens in a single
authorization process. There has already been some discussion about
this topic roughly a year ago:
- http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
- http://www.iet
Hi Eran,
> ... Until everyone deploys TLS, including such non-TLS bits in a TLS
> page cause the browser to show a broken TLS state in the address bar.
> For most web users, that's more of a red flag (valid TLS but with some
> resources loaded without TLS) than no TLS at all.
And in fact, in any
> -Original Message-
> From: Tim [mailto:tim-proje...@sentinelchicken.org]
> Sent: Thursday, June 09, 2011 7:42 AM
> To: Robert Sayre
> Cc: Eran Hammer-Lahav; OAuth WG; apps-disc...@ietf.org
> Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC
> Authentication Scheme
>
> > Dige
11 matches
Mail list logo
