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 RFC6749
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 jric...@mitre.org wrote:
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 wmills_92...@yahoo.com:
I
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
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 tors...@lodderstedt.net
To: William Mills
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
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 phil.h...@oracle.com
To: William Mills wmills_92...@yahoo.com
Cc: Torsten
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
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
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.
Because we're goign to want a single implementation, not N.
From: Tim Bray twb...@google.com
To: William Mills wmills_92...@yahoo.com
Cc: Torsten Lodderstedt tors...@lodderstedt.net; IETF oauth WG
oauth@ietf.org
Sent: Friday, February 15, 2013 8:49 AM
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 wmills_92...@yahoo.com wrote:
I've brought it up before, but I think it might be worthwhile, at least as
an exercise, to
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
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
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
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
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
17 matches
Mail list logo
