If we were using PKCS#7 for certs, then why not PKCS#7 the payload as well?
(No - I am not proposing to do it. Doing so with AES-128,192,256 is
prohibitive in some language such as PHP, but just as a point of
discussion to close this.)
On Tue, Jun 22, 2010 at 6:33 PM, Ben Laurie b...@google.com
Hi Dick,
you're right - after actually reading the paper :-), I agree that if you
have both sender and receiver in your payload, the order (of encrypting and
signing) doesn't seem to matter.
I'm still hesitant, though, to optimize for the encryption use case now
(even though I do believe it will
On 2010-07-15, at 5:29 PM, Dirk Balfanz wrote:
Hi Dick,
you're right - after actually reading the paper :-), I agree that if you have
both sender and receiver in your payload, the order (of encrypting and
signing) doesn't seem to matter.
I'm still hesitant, though, to optimize for
Hi OAuthers,
First of all, I think I should introduce myself. I work at Facebook on the
Platform team (anything not facebook.comhttp://facebook.com). Before this I
was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth
applications and libraries, both at Yahoo and in
I agree we don't want to end up like other protocols that were too generic. :)
The use case I am arguing for is sending encrypted tokens. Higher levels of
assurance require this and various people brought this up as a requirement when
WRAP was presented at IIW 09B.
-- Dick
On 2010-07-10, at
On 2010-07-10, at 1:42 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-10, at 1:21 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt dick.ha...@gmail.com wrote:
* the signature comes before the payload
* we
On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt dick.ha...@gmail.com wrote:
Obviously anything besides what you need for your use case adds complexity.
The question is: are you willing to accept some complexity so that it works
for use cases than yours? If not, then perhaps you should just define
On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Can we get an updated document based on the feedback received?
Sure - I just got back from my vacation. I'll read through the thread and
update the docs.
Cheers,
Dirk.
EHL
On 6/21/10 12:04 AM, Dirk Balfanz
would your proposal allow to issue and use HMAC Verification Keys in the
same way as the old token secrets, i.e. an AS would issue such keys
along with tokens to the OAuth client? A special key id could be used to
indicate this scenario.
regards,
Torsten.
Am 21.06.2010 09:04, schrieb Dirk
What's the purpose of leaving out the key ID?
It's one more field that developers have to learn and configure and type in. We
should keep the simple case simple, while allowing for more complex cases. I
think the fact that many providers now offer only a single, shared secret is an
indication
On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard lshep...@facebook.com wrote:
What's the purpose of leaving out the key ID?
It's one more field that developers have to learn and configure and type in.
We should keep the simple case simple, while allowing for more complex
cases. I think the fact
+1 for optional
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Breno
Sent: Friday, June 25, 2010 11:02 AM
To: Luke Shepard
Cc: hannes.tschofe...@gmx.net; OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Fri, Jun 25, 2010
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write out algorithm instead of `alg`?
How do you generate the body hash?
Does websafe-base64-encoded mean that I can't just blindly use my
btw, I wrote a very naive PHP sample. http://gist.github.com/448164
On Mon, Jun 21, 2010 at 11:03 PM, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we
On 22 June 2010 02:40, Manger, James H james.h.man...@team.telstra.com wrote:
Nat and Ben,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With PEM, you can just concatenate ... )
With
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write out algorithm instead of `alg`?
How do you generate the body hash?
On 2010-06-21, at 11:03 PM, David Recordon wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
it is the ID of the key, not the client -- used to rollover keys
Does websafe-base64-encoded mean
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
it is the ID of the key, not the client -- used to rollover keys
I don't think
:43 AM
To: Dick Hardt; hannes.tschofe...@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt
dick.ha...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use
On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie b...@google.com wrote:
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write
Aside/my $.02: This is a key issue which Salmon+Magic Signatures
evades by essentially treating the HTTP request (the method, URL,
headers, etc.) as advisory/transport hints, to be ignored when reading
the data, and making sure the protocol works even if the data is sent
via carrier pigeon;
...@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth
...@ietf.org] On Behalf
Of
Brian Eaton
Sent: Tuesday, June 22, 2010 9:43 AM
To: Dick Hardt; hannes.tschofe...@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com
wrote:
Thanks for writing
...@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardtdick.ha...@gmail.com
wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth
Hi guys,
I think I owe the list a proposal for signatures.
I wrote something down that liberally borrows ideas from Magic
Signatureshttp://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html,
SWT http://groups.google.com/group/WRAP-WG/files, and (even the name from)
JSON Web
On 21 June 2010 08:04, Dirk Balfanz balf...@google.com wrote:
Hi guys,
I think I owe the list a proposal for signatures.
I wrote something down that liberally borrows ideas from Magic Signatures,
SWT, and (even the name from) JSON Web Tokens.
Here is a short document (called JSON Tokens) that
Hi Dirk,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With PEM, you can just concatenate ... )
And here is some comments:
If body_hash is not used, it seems it is just doing the client
Thanks for writing this up Dirk.
I would suggest that the token be:
payload . envelope . signature
This enables the payload to be encrypted and independent from the envelope.
Token signing, verification, encryption and decryption code can then be generic
and not understand the
On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie b...@google.com wrote:
On 21 June 2010 14:22, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With
On 21 June 2010 16:33, Nat Sakimura sakim...@gmail.com wrote:
On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie b...@google.com wrote:
On 21 June 2010 14:22, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do
On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this up Dirk.
I would suggest that the token be:
payload . envelope . signature
This enables the payload to be encrypted and independent from the envelope.
Token signing, verification, encryption and
I'm not emphatic about either, but my vote is to remove the envelope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this up Dirk
On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie b...@google.com wrote:
On 21 June 2010 08:04, Dirk Balfanz balf...@google.com wrote:
Hi guys,
I think I owe the list a proposal for signatures.
I wrote something down that liberally borrows ideas from Magic
Signatures,
SWT, and (even the name
On Mon, Jun 21, 2010 at 6:22 AM, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With PEM, you can just concatenate ... )
Good question:
Nat and Ben,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With PEM, you can just concatenate ... )
With DER you can concatenate, too, of course. There's also PKCS#n (for
some value
36 matches
Mail list logo
