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
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,
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
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
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
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
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.
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
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
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
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
>> 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 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
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
___
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
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
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
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
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
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
+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
21 matches
Mail list logo
