Subject: [OAUTH-WG] proposal for signatures

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Jun 2010 00:04:55 -0700

Hi guys,

I think I owe the list a proposal for signatures.

I wrote something down that liberally borrows ideas from Magic
Signatures<http://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 Tokens<https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#>
.

Here is a short document (called "JSON Tokens") that just explains how to
sign something and verify the signature:
http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension of JSON Tokens that can be used for signed OAuth
tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

Here is a different extension of JSON Tokens that can be used for 2-legged
flows. The idea is that this could be used as a drop-in replacement for SAML
assertions in the OAuth2 assertion flow:
http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some
code<http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures>to
implement this as a proof-of-concept.

Thoughts? Comments?

Dirk.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Jun 2010 12:18:28 +0100

On 21 June 2010 08:04, Dirk Balfanz <[email-masked]> wrote:
> I wrote something down that liberally borrows ideas from Magic Signatures,
> SWT, and (even the name from) JSON Web Tokens.

"signature is a base64-encoded string of the signature bits." should
be websafe-base64?

"the current time is not after the expiration time of the token
(defined as not_before + session_length)" should be not_before +
token_lifetime, right? But I'd prefer a not_after instead.

What is a Service Descriptor? Is this something to do with webfinger,
or something else?

In the HMAC keys section you describe the keys as symmetric, which is
strictly accurate, but more normally called shared keys for this use.

Obviously you'll need to be a bit more specific about what you mean by
"RSA-SHA256".

> tokens:

As you know, I hate the term "non-repudation". Can't you just call it "signing"?

"Protection against leaked authentication tokens: Protocols such as
OAuth2 use bearer tokens, which may leak when used over non-SSL.
Signing requests when using bearer tokens lets the recipient of such a
request verify that the issuer of the request was a legitimate holder
of the bearer token." - only true if you make the checking of the
nonce a MUST instead of "may". And even then, MitM wins, of course.

Why is body_hash optional?

> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

You use the abbreviation AS before the full name Authorization Server.

> I also have started to write some code to implement this as a> proof-of-concept.
>
> Thoughts? Comments?

Nice.

> Dirk.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 21 Jun 2010 22:22:53 +0900

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
authentication via asymmetric crypto.
This is a valid use case, and actually is quite nice. I think this is
the main use case.

If we wanted to make sure that the request itself is not tampered, we
need to sign the body.
For this, I somehow feel that Magic Signatures is more interoperable
since it actually sends the armored ASCII strings with it.

=nat

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Jun 2010 14:26:47 +0100

> (With PEM, you can just concatenate ... )

With DER you can concatenate, too, of course. There's also PKCS#n (for
some value of n which I forget ... 12?) which allows bundling of cert
chains.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 21 Jun 2010 07:43:14 -0700

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 payload of the token. 

I would only include issuer, key_id and alg in the envelope. 

Audience, scope, nonce, and validation time information etc. would be in the payload.

-- Dick

On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote:

> 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 just explains how to sign something and verify the signature:
> Here is an extension of JSON Tokens that can be used for signed OAuth tokens:
> Here is a different extension of JSON Tokens that can be used for 2-legged flows. The idea is that this could be used as a drop-in replacement for SAML assertions in the OAuth2 assertion flow:
> I also have started to write some code to implement this as a proof-of-concept. 
> 
> Thoughts? Comments?
> 
> Dirk.
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 22 Jun 2010 00:33:12 +0900

> some value of n which I forget ... 12?) which allows bundling of cert

That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the
private key, though.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Jun 2010 16:43:41 +0100

> That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the

Doesn't have to, though admittedly it isn't quite designed for this
application. Presumably if we went down this route we'd have do no
encryption and a well-known "secret" for the HMAC key.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 21 Jun 2010 09:48:35 -0700

On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <[email-masked]> wrote:
> Token signing, verification, encryption and decryption code can then be
> generic and not understand the payload of the token.

I think you can still do that even if payload and envelope are combined.

the signed json would become:

{
    signer: <whoever-signed>
    encrypted_for: <intended-destination>
    encrypted_payload: <the-encrypted-payload>
}

---

From: Justin Smith <[email-masked]>
Date: Mon, 21 Jun 2010 17:54:30 +0000

I'm not emphatic about either, but my vote is to remove the envelope.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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 <[email-masked]> wrote:
> Token signing, verification, encryption and decryption code can then 
> be generic and not understand the payload of the token.

{
    signer: <whoever-signed>
    encrypted_for: <intended-destination>
    encrypted_payload: <the-encrypted-payload> } _______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 21 Jun 2010 11:51:17 -0700

A couple of advantages of separating:

1) everything but the envelope data (key_id, signer, algorithm) gets
encrypted

2) if the encrypted data is an object in the JSON, then it has been base64
encoded, and then gets base64 encoded again. Much more efficient to include
the base64 encoded binary of the encrypted data as a separate field (this is
what motivated me to this separation to begin with

-- Dick

On Mon, Jun 21, 2010 at 10:54 AM, Justin Smith <[email-masked]>wrote:

>     encrypted_payload: <the-encrypted-payload> }

---

From: Brian Eaton <[email-masked]>
Date: Mon, 21 Jun 2010 12:00:21 -0700

> 1) everything but the envelope data (key_id, signer, algorithm) gets

I think this is true of my proposal as well...?

> what motivated me to this separation to begin with

Yeah, this would be a problem.

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Jun 2010 18:14:42 -0700

On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie <[email-masked]> wrote:

> Signatures,

Yes.

> token_lifetime, right?

Yes.

> But I'd prefer a not_after instead.
>

Either way is fine with me. I picked token_lifetime b/c it tends to take up
a little less space than a not_after, but I don't feel strongly about it.

> What is a Service Descriptor? Is this something to do with webfinger,

Something else. I'm proposing that an OAuth Client be identifiable by a URL.
You resolve the URL, you get everything you need to know about that Client.
Simpler than webfinger.

> Obviously you'll need to be a bit more specific about what you mean by

Right. Any suggestions what RSA-SHA256 should specifically refer to? If I
stick that into a Signature.getInstance() call in Java, it returns
_something_. Any idea what that is? I'd like say that whatever that is is
what I mean by RSA-SHA256.

> As you know, I hate the term "non-repudation". Can't you just call it

What would you say is the advantage of public-key signatures over shared-key
signatures? I do want to point out that this proposal includes public-key
signatures, and therefore brings to advantages to the table.

> nonce a MUST instead of "may". And even then, MitM wins, of course.

MITM wins while the token is valid as per not_before and token_lifetime (or
not_after).

> Why is body_hash optional?

Maybe some Clients/PRs don't care? I remember that in OAuth 1, we couldn't
ever get agreement on what to do about POST body signing, so I made it
optional. I'm not going to stand in the way if people want this to be
required.

> You use the abbreviation AS before the full name Authorization Server.

Oops - sorry. :-) I'll try to do a revision later tonight...

Thanks for the feedback!

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Jun 2010 18:20:35 -0700

> (With PEM, you can just concatenate ... )

Good question: strawman answer: Don't put cert chains into the server info
document. The verifier hopefully fetches the server info document over SSL,
and can verify all the cert chains it wants in the SSL layer. We simply need
a public key in the server info document. The option to include a
certificate is purely there in case it's easier for you to generate an X.509
cert than a Magic Key. For example, if you already have concatenated PEMs,
throw all but the first away, remove the newlines, prepend "X509." and you
have a valid representation of a public key, as far as JSON Tokens are
concerned.

What do you think?

Dirk.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 Jun 2010 11:40:48 +1000

Nat and Ben,

> private key, though.

A *.p7c file can be used to hold any number of certificates. It is a BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) standard [RFC 5652<http://tools.ietf.org/html/rfc5652#section-5.1>]. It is the ASN.1 syntax used for S/MIME signed email. If you only want to send certificates, just leaving out the content-to-be-signed, and the signatures.

Such a file can hold any number of certificates, including public-key certificates, attribute certificates, or other certificate formats.

It can also hold CRLs and other revocation information (including OCSP responses as per draft-turner-additional-cms-ri-choices<http://tools.ietf.org/html/draft-turner-additional-cms-ri-choices>).

CMS/PKCS#7 is better for this purpose than PKCS#12.

--

James Manger

---

From: David Recordon <[email-masked]>
Date: Mon, 21 Jun 2010 23:03:15 -0700

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
languages built in base64 encode function?

Don't we still have the more fundamental question to answer about
decoupling what's being signed from the underlying HTTP request?

--David

---

From: David Recordon <[email-masked]>
Date: Tue, 22 Jun 2010 01:11:08 -0700

btw, I wrote a very naive PHP sample. http://gist.github.com/448164

---

From: Ben Laurie <[email-masked]>
Date: Tue, 22 Jun 2010 10:28:30 +0100

>> "signature is a base64-encoded string of the signature bits." should

I think there are a couple of other places that also need this change.

> a little less space than a not_after, but I don't feel strongly about it.

not_after is in line with X.509, and also means implementations are a
few characters shorter :-)

> You resolve the URL, you get everything you need to know about that Client.

Why? What's wrong with webfinger?

> what I mean by RSA-SHA256.

RSA in Java Signature means a PKCS#1 signature (see
http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#Signature).
Of course, there are actually two PKCS#1 signature schemes, and the
Java docs are quite unclear about which they use, but reading between
the lines, I'd say that "SHA256withRSA" (presumably what you meant by
"RSA-SHA256"?) yields a PKCS1_v1_5 signature (what they call
RSASSA-PKCS1_v1_5) and "SHA256withRSAandMGF1" yields an RSASSA-PSS
signature, which is recommended for new applications.

> signatures, and therefore brings to advantages to the table.

Well, the advantages are that

a) the signature cannot be forged by the verifier (assuming no key leakage).

b) verifying key distribution is easier (since it is public).

I don't know of a short way to describe this other than "public key"
or "asymmetric".

> MITM wins while the token is valid as per not_before and token_lifetime (or

Right.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 22 Jun 2010 10:33:34 +0100

On 22 June 2010 02:40, Manger, James H <[email-masked]> wrote:
> A *.p7c file can be used to hold any number of certificates. It is a
> BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS)
> standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If
> you only want to send certificates, just leaving out the
> content-to-be-signed, and the signatures.

Ah, thanks, I thought there was something less kludgey than PKCS#12.

>
>
>
> Such a file can hold any number of certificates, including public-key
> certificates, attribute certificates, or other certificate formats.
>
> It can also hold CRLs and other revocation information (including OCSP
> responses as per draft-turner-additional-cms-ri-choices).
>
>
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 22 Jun 2010 10:36:39 +0100

> languages built in base64 encode function?

No, you need the websafe alphabet, which substitutes '-' and '_' for
'+' and '/' in the standard alphabet. Which reminds me, Dirk needs to
specify whether padding is used.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 07:17:10 -0700

> instead at least for OAuth?

it is the ID of the key, not the client -- used to rollover keys

> languages built in base64 encode function?

correct -- but a growing number of languages are supporting websafe

> decoupling what's being signed from the underlying HTTP request?

I have no idea what you mean by this question

-- Dick

---

From: Brian Eaton <[email-masked]>
Date: Tue, 22 Jun 2010 09:43:29 -0700

> it is the ID of the key, not the client -- used to rollover keys

I don't think key id is necessary, but adding Hannes since he called
me crazy for saying that at IIW. =)

The average client is going to have very few keys.  Probably just 1.
3 at the outside.

If a server needs to verify, it can literally iterate over all of the
keys associated with the client until it finds the right one.

There is some precedent for this approach:
http://support.microsoft.com/kb/906305/en-us.

Cheers,
Brian

---

From: "William Mills" <[email-masked]>
Date: Tue, 22 Jun 2010 09:49:05 -0700

Having a key ID is an optimization.  If you're using public key
signatures is having to do potentially 3x the signatures going to be a
problem?   

> Sent: Tuesday, June 22, 2010 9:43 AM
> To: Dick Hardt; [email-masked]
> Cc: OAuth WG
> I don't think key id is necessary, but adding Hannes since he 
> called me crazy for saying that at IIW. =)
> 
> If a server needs to verify, it can literally iterate over 
> all of the keys associated with the client until it finds the 
> right one.
>

---

From: John Panzer <[email-masked]>
Date: Tue, 22 Jun 2010 10:07:40 -0700

> specify whether padding is used.

(Padding _is_ part of the base64 specification IIRC; I think it'd be
sufficient to artfully include it in the primary example -- and have a
second example crafted so that there happens to be zero padding :) ).

You can construct base64url() from base64() plus a substitution pass for -+
and _/ so it doesn't seem too onerous.  (Make sure to include one of these
characters in the examples too.)

> > decoupling what's being signed from the underlying HTTP request?

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; all
important information must be contained in the signed, structured body.
 This is much much harder if you have to deal with totally arbitrary kinds
of requests with arbitrary semantics.

This also means that you're effectively using HTTP as a simple transport to
move envelopes around, in much the same way you can use the ocean to
transport messages in bottles around, but a bit more efficiently.  I've
banged my head against this a bit and have not come up with a better
solution but if there is one I'd love to hear it.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 22 Jun 2010 17:30:49 +0000

> If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one.

Depends on how the server stored the keys, this can be a very expensive operation w/o a key_id to match/index on

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Tuesday, June 22, 2010 9:43 AM
To: Dick Hardt; [email-masked]
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures

> it is the ID of the key, not the client -- used to rollover keys

I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =)

If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one.

Cheers,
Brian

---

From: Justin Richer <[email-masked]>
Date: Tue, 22 Jun 2010 13:42:51 -0400

> 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; all important information must be contained in the
> signed, structured body.  This is much much harder if you have to deal
> with totally arbitrary kinds of requests with arbitrary semantics.
> 
> 
> This also means that you're effectively using HTTP as a simple
> transport to move envelopes around, in much the same way you can use
> the ocean to transport messages in bottles around, but a bit more
> efficiently.  I've banged my head against this a bit and have not come
> up with a better solution but if there is one I'd love to hear it.
>  

+1

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 12:14:34 -0700

I could imagine an architecture striving to be efficient, scalable,
distributed and secure where there are hundreds of servers each with a
unique private key baked into each server. All the public keys would be in
one file.

Having a key id would help debugging as well as the signer is clearly
indicating which key should be used. If the signing fails, it could be the
key, could be signature calculation, could be ...

The downside of having a key_id seems heavily outweighed by the advantages
to me.

On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin <[email-masked]>wrote:

> If a server needs to verify, it can literally iterate over all of the keys
> associated with the client until it finds the right one.
>

---

From: David Recordon <[email-masked]>
Date: Tue, 22 Jun 2010 12:20:45 -0700

All of the OAuth 1.0 implementations which I'm aware of either have
the server provide a shared secret to the client or the client upload
their public key to the server.

In the case of the server providing a shared secret to the client,
what would the value of key_id be?

In the case of a client uploading their public key to the server, what
would the value of key_id be?

Thanks,
--David

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 12:59:03 -0700

David

key_ids are used when you need to identify which key to use of all the keys
you might have. If you are doing discovery of document that is bound to the
identifier of the signer, this is useful. Since OAuth 1.0 did not have
discovery and required an out of band key management process, key_ids have
little value.

To answer your question, key_ids dont' make sense if the keys are being
managed how you describe them. I would suggest that key_ids are not included
if public keys are managed independent from how Dirk had described them be
discovered.

I don't think key_ids make sense for shared secrets as they inherently have
an out of band process for sharing them.

If you would like to learn more about cryptography, I have found Bruce
Schneier's book Applied Cryptography to be pretty educational. Here is a
link to the Kindle version:

http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1

-- Dick

On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <[email-masked]>wrote:

> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin <[email-masked]
> >
> > wrote:
> >>
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Brian Eaton
> keys

---

From: David Recordon <[email-masked]>
Date: Tue, 22 Jun 2010 13:45:14 -0700

Hey Dick, in answering my questions you made my point. If keys are
managed out of band – as is done in OAuth 1.0 and what was done in the
OAuth 2.0 Core spec until signatures were extracted – then having a
key id is not needed. I certainly understand what they're used for,
but don't find them relevant as part of the OAuth conversation today.

And yes, Applied Cryptography is worth reading. :)

--David

On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <[email-masked]> wrote:
>> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin
>> > <[email-masked]>
>> > wrote:
>> >>

---

From: George Fletcher <[email-masked]>
Date: Tue, 22 Jun 2010 17:35:49 -0400

The only additional value might be during "key rotation". If key_id is 
removed, then both (or n) have to be checked. Probably not a huge issue.

Thanks,
George

On 6/22/10 4:45 PM, David Recordon wrote:
> managed out of band -- as is done in OAuth 1.0 and what was done in the
> OAuth 2.0 Core spec until signatures were extracted -- then having a
> On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt<[email-masked]>  wrote:
>    
>> David
>> On Tue, Jun 22, 2010 at 12:20 PM, David Recordon<[email-masked]>
>> wrote:
>>      
>>> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt<[email-masked]>  wrote:
>>>        
>>>>> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt<[email-masked]>
>>>>> wrote:
>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Jun 2010 16:17:26 -0700

George: David's example is that keys are managed out of band. When you rotate the key, you tell the other side the new key, then use it. 

David: I would hope that we would be able to move past the horrible key management that we have today to an architecture using published public keys so that client and server don't need a different out of band identity system to support this one. :)

-- Dick

On 2010-06-22, at 2:35 PM, George Fletcher wrote:

> The only additional value might be during "key rotation". If key_id is removed, then both (or n) have to be checked. Probably not a huge issue.
> 
> Thanks,
> George
>

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Jun 2010 22:57:55 -0700

Hi Dick,

interesting point about encrypted payloads.

People more cryptographically-inclined than me might want to chime in, but I
do seem to remember that there is a "correct" choice among the
"encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search
seems to suggest that the latter is what you want:
https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx
.

So I would suggest that encrypted payloads are implemented as an encryption
of a JSON Token, as in:

encrypted_token = encryption(JSON_Token) || "." || envelope
envelope = base64(JSON(everything you need to know to decrypt))

What do you think?

Dirk.

On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <[email-masked]> wrote:

> I wrote something down that liberally borrows ideas from Magic Signatures<http://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 Tokens<https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#>
> .
>
> I also have started to write some code<http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures>to implement this as a proof-of-concept.
>
> Thoughts? Comments?
>
> Dirk.
>

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Jun 2010 23:09:47 -0700

> Why? What's wrong with webfinger?

webfinger is for resolving email-like identifiers. Sometimes, that's all you
have (e.g., when you have a login box and users insist on typing email
addresses into that login box). But we can make things much simpler if the
identifiers that need to be resolved are already http(s) URLs (and we don't
assume that they need to resolve to display-able HTML). If we're in that
situation (and I'm arguing that here we can be if we want to) then
"discovery" basically disappears as a problem - you simply fetch the URL and
you have the information you want right there.

Dirk.

> >> > flows. The idea is that this could be used as a drop-in replacement
> for
> >> > SAML

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Jun 2010 23:17:30 -0700

In my write-up, I'm saying that if you provide the shared key and you don't
care about rotating it, then the verifier can ignore the key_id (the issuer
would presumable not include the key_id). Same for public keys - if you
upload them out of band and you don't think you'll ever change them, then
the key_id is not necessary. I would argue that either of those practices is
not advisable (despite the fact that we've all been doing it for OAuth 1),
so I think the key_id is useful.

Dirk.

On Tue, Jun 22, 2010 at 1:45 PM, David Recordon <[email-masked]> wrote:

> >> > unique private key baked into each server. All the public keys would
> be
> >> > in
> >> > one file.
> >> >> Depends on how the server stored the keys, this can be a very
> expensive
> >> >> operation w/o a key_id to match/index on
> >> >>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Jun 2010 10:56:36 +0100

> but don't find them relevant as part of the OAuth conversation today.

I don't understand why they are unnecessary no matter how keys are
managed: if there's ever a possibility that you might have more than
one key for someone, then key IDs are a useful optimisation.

Put it another way: what's the purpose of leaving out the key ID?

---

From: Breno <[email-masked]>
Date: Fri, 25 Jun 2010 07:40:36 -0700

Key ids are an optimization in the case of rotating public keys, but pretty
much an operational requirement if you wish to support automatic rotation of
shared keys.

On Jun 23, 2010 2:56 AM, "Ben Laurie" <[email-masked]> wrote:

On 22 June 2010 21:45, David Recordon <[email-masked]> wrote:
> Hey Dick, in answering my quest...

> On Tue, Jun 22, 2010 at 12:5...

---

From: Luke Shepard <[email-masked]>
Date: Fri, 25 Jun 2010 10:51:28 -0700

> 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 that the key ID is not required.

On Jun 25, 2010, at 7:40 AM, Breno wrote:

Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys.

On Jun 23, 2010 2:56 AM, "Ben Laurie" <[email-masked]<mailto:[email-masked]>> wrote:

> On Tue, Jun 22, 2010 at 12:5...

<ATT00001..txt>

---

From: Breno <[email-masked]>
Date: Fri, 25 Jun 2010 11:01:36 -0700

On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard <[email-masked]> wrote:
> 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 that the key ID is not required.

Are you arguing here that the key_id should be an optional field, or
that it should not be part of the specification at all?

-- 
Breno de Medeiros

---

From: "William Mills" <[email-masked]>
Date: Fri, 25 Jun 2010 11:35:19 -0700

+1 for optional 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Breno
> Sent: Friday, June 25, 2010 11:02 AM
> To: Luke Shepard
> Cc: [email-masked]; OAuth WG
> > cases. I think the fact that many providers now offer only 
> a single, 
> > shared secret is an indication that the key ID is not required.
> 
> Are you arguing here that the key_id should be an optional 
> field, or that it should not be part of the specification at all?
> 
> > Key ids are an optimization in the case of rotating public 
> keys, but 
> > pretty much an operational requirement if you wish to support 
> > automatic rotation of shared keys.
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Jun 2010 23:16:53 +0200

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 Balfanz:
> Signatures 
> <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>, 
> from) JSON Web Tokens 
> <https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#>. 
>
>
> Here is a short document (called "JSON Tokens") that just explains how 
> to sign something and verify the signature:
> Here is a different extension of JSON Tokens that can be used for 
> 2-legged flows. The idea is that this could be used as a drop-in 
> replacement for SAML assertions in the OAuth2 assertion flow:
> I also have started to write some code 
> <http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures> 
> to implement this as a proof-of-concept.
>
> Thoughts? Comments?
>
> Dirk.
>
>