(Please take a break from the other threads and read this with an open mind. I
have tried to make this both informative and balanced.)
--- IETF Process
For those unfamiliar with the IETF process, we operate using rough consensus.
This means most people agree and no one strongly objects. If some
Am 27.09.2010 22:53, schrieb Dick Hardt:
On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
If you know me then you'll know that I'm generally one of the last people to
talk about Alice and Bob. That said, there are a lot of technical proposals
flying across the list with very little shared understanding of the
problem(s) we're trying to solve.
>From what I've seen there are two distinct
Generally speaking, every major provider except Microsoft.
More specifically, over 50 companies last time I counted which was a year ago
when we coordinated 1.0a.
An outdated partial list: http://wiki.oauth.net/ServiceProviders
1.0a signatures are widely deployed, secure, and have plenty of lib
Still no real answers ...
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, September 27, 2010 9:46 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: RE: Proposal: OAuth 1.0 signature in core with revision
You must be joking about 1.0a signature deployment. It's also nic
Are you going to write it? Still waiting for the best practices guide for 1.0
people suggested over three years ago.
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, September 27, 2010 12:04 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
>
You must be joking about 1.0a signature deployment. It's also nice that half a
day is your measurement for obtaining consensus.
EHL
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Monday, September 27, 2010 2:38 PM
To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: RE: Proposa
Maybe, but that's something we actually have wide consensus that is not needed.
The current draft replaces signatures for obtaining an access token using other
means.
EHL
From: Lukas Rosenstock [mailto:l...@lukasrosenstock.net]
Sent: Monday, September 27, 2010 2:43 PM
To: Eran Hammer-Lahav
Cc:
Dirk and I both posted JSON Token drafts on Thursday. They are at
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which
I'll refer to as Dirk's draft) and
http://self-issued.info/docs/draft-goland-json-web-token-00.html (which I'll
refer to as JWT). This note points
Thanks for the detailed comments, James. I'll take them into account when
producing the next draft.
Yes, the motivation behind Section 5, Rule 5 is exactly motivated by the
sentiments that Ben so ably expressed and you elaborated upon. Note that there
*is* a caveat in place "When used in a se
From: Eran Hammer-Lahav
>* If HTTPS is to remain optional for protected resource requests, a
>signature-based alternative is required.
I agree. If we're going to have signatures for this reason, we should have at
least one use case on Zeltsan's use case list
(https://datatracker.ietf.org/doc/d
2010/9/27 Eran Hammer-Lahav
> I would also be happy with the core only dealing with **getting** a token,
> and moving all text about **using** a token to other documents. This will
> produce three parts:
>
>
>
> 1. Getting a document
>
> 2. Using bearer tokens
>
> 3. Using crypt
In my opinion, there could be two arguments against including 1.0 signatures
into the core:
1) The spec will be too long.
2) The signature mechanism isn't good, so it would be replaced with
something else anyway.
Is 1) a concern? For 2), I think the adoption of OAuth 1.0 speaks for the
signature me
Not seeing an overwhelming support for doing this, how many interoperable
deployments of 1.0a signature are there?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Sunday, September 26, 2010 11:44 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-W
On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
> Am 27.09.2010 19:11, schrieb Anthony Nadalin:
>> What is needed is needed is the security considerations section complete, I
>> don't think that the signature specification has to be in the core to be
>> complete, there are previsions to
I've got XML-based protocols here that we want to protect with OAuth,
and so having to deal with a JSON blob is less than optimal for us. Ages
ago, we decided to make JSON be the One True Encoding for the core spec,
and I commented that I was fine with that if we had a way to represent
things in ot
Arguments like this are why I have been advocating for separating the
"developers guide" from the "protocol spec" for a while now. I believe
that they support two different audiences.
A developers' guide then has the option of combining multiple specs,
selecting profiles of those specs, and layin
Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the
I also think we should focus on finishing OAuth 2 core and deal with
signatures in a separate spec.
Not sure what are optional 1.0a signatures really buying.
Client developers given an option in most cases will go with bearer
tokens. If server developers want to enforce signatures, or provide
the
Myself and others feel that a spec for how to sign a request would be useful
for other specifications. As I noted in a previous email, there was dismay when
the signing of an OpenID message was very similar, but different than the
signing in OAuth 1.0A.
Signing messages was a huge stumbling bl
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the signature specification would be in the security
Bearer tokens are appropriate for some use cases but not all, signed requests
are appropriate for a different (intersecting?) set. Both have use cases where
they are not ideal or appropriate.We should address both in the core spec,
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org
I mistyped, and just noticed that it looked strange. I meant to type:
Igor Faynberg wrote:
...
But if both the OAuth signatures and the OAuth core specifications are
complete and going for approval at the same time, why not actually
have them in the same spec, especially given that THE (not "
I would also be happy with the core only dealing with *getting* a token, and
moving all text about *using* a token to other documents. This will produce
three parts:
1. Getting a document
2. Using bearer tokens
3. Using cryptographic tokens
Part 3 can include both the JSON
Well said.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Igor Faynberg
> Sent: Monday, September 27, 2010 9:42 AM
> To: Eve Maler
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Basic signature support in the core specification
>
> I think Tor
It matters if we publish one main specification and then a bunch of extensions.
It doesn't matter if we break the core specification into multiple functional
parts, where using bearer tokens are also outside core. My concern is solely on
the impression and education the specification provides. P
I think it would also help with handling revisions over time. Changes to
signature specifications, etc over time, won't impact the core specification --
keeping it stable and well understood.
Maybe a compromise is to include the 1.0a stuff in the core spec as "legacy"
(since it was in the 1.0 c
I think Torsten's previous comment explains it well: We cannot expect
approval of the core, if security is not sufficiently addressed. I also
agree that it cannot be addressed without the signature mechanism
clearly specified. Therefore, if anything is going to delay the core, it
is the absence
Hi all
I wonder whether the question of "signature in the main specification or
in a separate document" does not really matter. It is purely a matter of
document management style.
The important question is whether there will be a **mandatory to
implement** or **mandatory to use** someone in the
Since you were asking for votes earlier, I'll add a -1. I believe the industry
would be better served by approving a draft soon without signatures, and then
working on signatures separately.
-- Mike
From: oauth-boun...@ietf.org [mailt
Nat had reviewed Yaron's and my proposal and encouraged us to proceed with it.
Yes, it's intentionally general and not OAuth specific (just like SWTs were).
The JWT token type will have uses outside OAuth. Dirk and we agree that we
need to come up with a unified JSON token spec.
Later today
Mike and Yaron's proposal is different from Nat's though. Nat's is based
directly around OAuth versus explicitly defining a separate signing
mechanism and then a second spec to map it into OAuth. It also supports
fewer options (no unsigned tokens for example) which makes it easier to
understand wit
So we have been working with Nat on the signature proposal and talking to Nat
he agrees that the JWT proposal is well under way, what I would like to make
sure is that we merged in with your proposal
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk
Balfanz
Sent: Mo
I'm just as confused :-) I think what happened is that I posted a signature
draft and then didn't follow up. Nat then very kindly agreed to help and put
out a draft, but that also didn't get much momentum. So I went back and
re-did my drafts. Also, somewhere along the way, Yoran wrote a draft. At
l
On behalf of the co-authors I have submitted the revised version (-01) of the
draft on the OAuth use cases.
Link: https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ .
The draft lists the OAuth use cases. The document's objective is to identify
the use cases that will be a base for
The goal is to have a single unified draft.
From: David Recordon [mailto:record...@gmail.com]
Sent: Monday, September 27, 2010 7:00 AM
To: Nat Sakimura; Yaron Goland
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00
I'm a bit confused between the relationship of Nat's I-D and the doc
On 2010-09-27, at 8:35 AM, Eran Hammer-Lahav wrote:
> This is a stupid discussion.
I don't find this comment assists in finding a compromise, and a surprising
comment from someone who has stated they don't have firm beliefs in what the
spec does -- just wants to edit. You seem to have very str
On 2010-09-27, at 8:14 AM, Eran Hammer-Lahav wrote:
> That goes without saying.
No it does not. We are talking about normative specifications.
> Yes. Does this satisfy your concerns?
Depends on the quality of the extension mechanism.
Many of the people wanting signing want something stronger
This is a stupid discussion. We have been talking past each other (the working
group) for over a year. We are not likely to convince either side that bearer
tokens are bad or good idea.
All these experts reviewed WRAP in the strict context of their own environment,
with existing protocols and o
That goes without saying. Yes. Does this satisfy your concerns?
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Monday, September 27, 2010 6:46 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revision
As others ha
If you don't have an envelope, you don't have a standard way of looking at what
the contents might be. It is like HTTP headers vs the body of the message.
Fairly standard architectural practice that makes extensions easy instead of a
hack.
There are many use cases where encryption is needed. Pe
I'm a bit confused between the relationship of Nat's I-D and the documents
you and Mike recently posted. Is the goal to have one I-D? Nat's seems to
have fewer options and different modes which makes it easier to read and
understand.
On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland wrote:
> BTW,
I thought the discussion from June had most people not
needing encryption and an extra envelope. Given how Mike wrote this spec is
seems like supporting encryption with an extra envelope is possible, but
shouldn't be required if all you're doing is signing.
On Sun, Sep 26, 2010 at 9:55 PM, Dick Ha
As others have stated and I agree with, you also need an extension mechanism so
that other signature algorithms can be used. If there is no extension
mechanism, then the spec is saying this is the only signature mechanism
possible.
-- Dick
On 2010-09-26, at 11:44 PM, Eran Hammer-Lahav wrote:
I have gone through Brian's wrap security considerations and will
incorporate them into the security considerations for OAuth 2 that Torsten
and I will compile. We can run it past Brian too
http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityCons
I'll echo John's comments and remind you that Micrsoft, Yahoo! and Google
security experts with plenty of real world experience worked on WRAP which is
OAuth bearer tokens.
Microsoft, Google, Salesforce, Facebook and others have deployed bearer token
OAuth in production after internal security
On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav wrote:
>
>
> > -Original Message-
> > From: Dick Hardt [mailto:dick.ha...@gmail.com]
> > Sent: Sunday, September 26, 2010 11:21 PM
>
> > > What I absolutely object to is presenting a specification that to a
> new
> > reader will read as
47 matches
Mail list logo
