Justin,
Section 5.1 of RFC6749 "OAuth 2.0 Authorization Framework" states:
"The authorization server MUST include the HTTP "Cache-Control"
response header field [RFC2616] with a value of "no-store" in any
response containing tokens, credentials, or other sensitive
+1
Thanks for doing this, Justin!
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Friday, February 15, 2013 2:00 PM
To: internet-dra...@ietf.org
Cc: ;
Subject: Re: [OAUTH-WG] I-
HI,
On 15/02/13 18:29, William Mills wrote:
At this point I am more in favor converting the MAC token format to JWT
and getting the signature envelope added that way. It's really a matter
of time.
MAC stalled because folks see the HOK tokens as a replacement.
It's also been a matter of Justin a
Everyone, there's a new draft of DynReg up on the tracker. This draft tries to
codify the discussions so far from this week into something we can all read.
There are still plenty of open discussion points and items up for debate.
Please read through this latest draft and see what's changed and h
It's a pretty good shortcut to not have to deal with request tokens, to be able
to use scopes, to have access to client assertions and other methods of client
auth, and not have to do signing when talking to the AS. It's no shortcut when
talking to the RS, that's for sure.
-- Justin
On Feb 15
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth Dynamic Client Registration Protocol
Author(s) : Justin Richer
Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to turn
it into a token for 2.
Phil
Sent from my phone.
On 2013-02-15, at 13:04, William Mills wrote:
> >I've brought it up before, but I think it might be worthwhile, at least as
> >an exercise, to define a method to g
Because we're goign to want a single implementation, not N.
From: Tim Bray
To: William Mills
Cc: Torsten Lodderstedt ; IETF oauth WG
Sent: Friday, February 15, 2013 8:49 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th F
At this point I am more in favor converting the MAC token format to JWT and
getting the signature envelope added that way. It's really a matter of time.
MAC stalled because folks see the HOK tokens as a replacement.
It's also been a matter of Justin and I having the time to take it up again.
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:
If OAuth 1.0 is working well for them, why don’t they just keep using it?
I.e. if there’s already a good solution in place for people who require
secure authn/authz over insecure channels, why would we go the extra work
of
I wonder why it is proving so difficult to get a nearly completed MAC
draft completed ?
Is it because:
1. JWT was first in OAuth2 and thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3. Not enough motivation for some vendors to push MAC ?
Example, in cases where not a product but a deve
Exactly. And in the Flickr case replay of the same event is not a problem.
Thanks for keeping me honest, work just cranked the dial up to 11.5 so I'm a
bit distracted.
From: Phil Hunt
To: William Mills
Cc: Torsten Lodderstedt ; Mike Jones
; Justin Richer
Bill
You aren't objecting to https in the as communications correct? It is the rs
comms which is plain http where you want to protect the credential from theft.
Even replay is not the primary issue here.
Phil
Sent from my phone.
On 2013-02-15, at 8:09, William Mills wrote:
> I'll repeat
I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites
that OAuth 2 does not provide. Simply stating "move to HTTPS" is not a viable
response here.
From: Torsten Lodderstedt
To: William Mills
Cc: Mike Jones ; Justin Richer
; Phil
John - two separate issues here -
(i) for the symmetric key case, whether we need a key distribution
method for the client and AS/RS, and if so, what form should it take?
(ii) asymmetric case is quite different, I agree with your point - the
client could be pre-provisioned with a managed key
Remember that proof of possession is intended to prove that the client that was
issued the token is the one presenting it.
We tend to mix that up with replay and other protection issues.
To do this you don't need to authenticate the client.
The client can prove it controls a key by signing s
Hi Bill,
I think one needs to compare the costs/impact of HTTPS on one side and the
implementation of integrity protection and replay detection on the other. We
had this discussion several times.
regards,
Torsten.
Am 15.02.2013 um 08:08 schrieb William Mills :
> I fundamentally disagree with
Parameters that can be JSON lists rather than space separated sting s probably
should be unless there is some compelling reason as in scopes to keep them
space separated. May as well save unnecessary string parsing.
John B.
On 2013-02-15, at 11:58 AM, Justin Richer wrote:
> In case people
In case people missed a subtle change, I wanted to bring it to the
group's attention:
The metadata parameters "request_uri" and "grant_type" are now JSON
lists instead of space-separated lists of strings. The "scope" parameter
remains a space-separated string, taking its definition from RFC674
19 matches
Mail list logo
