+1
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, September 23, 2010 6:44 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Basic signature support in the core specification
>
> Since much of this recent debate w
Basically, this argument comes down to which validation pattern you
prefer.
OPTION 1:
0. Input = object + signature
1. Verify match between object data and HTTP fields
2. Verify signature over the object
OPTION 2:
0. Input = signature
1. Construct object data from HTTP fields
2. Verify signatu
Thanks Richard.
FWIW, RFC 5849 was stuck in IESG discuss until I the language regarding the use
of HTTPS with plaintext secrets was changed from SHOULD to MUST. Before the
change, the security consideration section clearly highlighted the danger in
not using HTTPS. OAuth 2.0 adds support for sh
I also agree with the observation about consensus being based on
individual voices.
I don't think it's accurate to say that signatures are a generic
security mechanism. As I would think we learned from OAuth 1.0[a], it
can actually be pretty subtle to define how signatures are used in a
First, thanks for putting this together. It provides a pretty comprehensive
story about the signed tokens proposal. I don't have much to add at this point
to the drafts.
My position, which I have expressed many times before about this approach is:
Any solution involving repeating the HTTP reque
On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav wrote:
> In part II, how is the signature bound to the HTTP request URI? I see the
> method and body, but not the request URI.
>
The request URI goes in the audience parameter that's defined in part I.
Dirk.
>
> EHL
>
>
>
> On 9/23/10 3:39 PM
In part II, how is the signature bound to the HTTP request URI? I see the
method and body, but not the request URI.
EHL
On 9/23/10 3:39 PM, "Dirk Balfanz" wrote:
Hi guys,
sorry it took a while, but here is an updated proposal. It's still in three
parts:
Part I is about "JSON Tokens" that c
Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
feature in the core spec, in line with the 1.0a signature approach.
This is not a vote, just taking the temperature of the group.
EHL
___
I agree with your point that consensus is based on individual voices.
I agree with Eric's points that signatures are a generic security mechanism and
that signatures should be in a separate spec.
-- Dick
On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:
> It is pretty clear from the recent
>> I believe that an OAuth 1.0a style signature
How about we start with exactly an OAuth 1.0a style signature? It may be
tricky, but there are still client libraries and some web-services that
handle them.
Like Tony, I also have not heard requests for a new signature approach, but
one of the reas
I have not seen the support to bring signature support back into core, have not
seen the public response either, all I have seen is you raising this as an
issue. We should keep the original agreement to move signatures out of core,
there is enough activity on signatures that we are confident tha
Why aren't these published as an IETF I-D?
EHL
On 9/23/10 5:40 PM, "Mike Jones" wrote:
FYI, I've also posted this at
http://self-issued.info/docs/draft-goland-json-web-token-00.html and
http://self-issued.info/docs/draft-goland-json-web-token-00.xml for easy
reference by those who didn't re
It is pretty clear from the recent public response that a core specification
without signatures is going to be viewed as weak and insecure. This has been my
position for over a year, and if it wasn't clear, I am going to continue
expressing it.
We have enough interest to get a basic signature s
Eric, Microsoft shares some of the same views, we would like to see the WG
charter expanded to cover these additional items (so we have a home for these),
we would like to see that proposed and agreed upon at the November meeting if
at all possible.
From: oauth-boun...@ietf.org [mailto:oauth-bo
FYI, I've also posted this at
http://self-issued.info/docs/draft-goland-json-web-token-00.html and
http://self-issued.info/docs/draft-goland-json-web-token-00.xml for easy
reference by those who didn't receive the original attachments.
Google wanted to re-state our long standing opinions on HTTP signature
mechanisms in the OAuth2 spec. The short version is that standards for
signing parts of an HTTP request have value in use-cases other than OAuth2,
and thus they should be defined outside the spec, and just referenced from
the s
Hi guys,
sorry it took a while, but here is an updated proposal. It's still in three
parts:
Part I is about "JSON Tokens" that can be used for all sorts of things, not
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html
Part II is about how to embed an OAuth toke
On Thu, Sep 23, 2010 at 2:08 PM, Brian Campbell
wrote:
> Do parameters defined by grant types really need a registry? I mean,
> a client only presents one access grant request at a time so it's not
> like there's potential for name conflicts. Am I missing something?
There could be conflicts with
Do parameters defined by grant types really need a registry? I mean,
a client only presents one access grant request at a time so it's not
like there's potential for name conflicts. Am I missing something?
On Wed, Sep 22, 2010 at 10:53 AM, Eran Hammer-Lahav wrote:
> It's a question of use case
I forgot to acknowledge in my previous message that the work that let to the
proposal was supported by NSF grant IIP-1013594.
--- On Thu, 9/23/10, Francisco Corella wrote:
From: Francisco Corella
Subject: Not requiring client registration
To: oauth@ietf.org
Date: Thursday, September 23, 2010,
I believe that this workshop is relevant to this group. You may consider
submitting a position paper.
Ciao
Hannes
Begin forwarded message:
> From: IETF Secretariat
> Date: September 21, 2010 12:00:02 AM GMT+03:00
> To: ietf-annou...@ietf.org
> Subject: Internet Privacy Workshop: 8 and 9 Decem
21 matches
Mail list logo
