From: Mike Jones
Sent: Thursday, October 14, 2010 9:15 PM
To: Dirk Balfanz; John Panzer; Brian Eaton; Marius Scurtescu; Nat
Sakimura; John Bradley; Paul Tarjan; Luke Shepard
Cc: Yaron Goland; Anthony Nadalin; Hervey Wilson; David Turner; Eric
Sachs; George Fletcher; Hideki Nara
Subject: Comparing the JSON signature proposals and convergence proposal
To my knowledge, there are four JSON Signature Proposals in active circulation or use at present:
· JSON Tokens using Magic Signatures by Dirk Balfanz and John Panzer of Google. Used in Salmon.
· JSON Simple Sign (JSS) by Nat Sakimura and John Bradley. Proposed for OpenID Artifact Binding. Accompanied by and JSON Encryption Envelope. Also, an alternative envelope syntax was proposed by Hideki Nara.
· Canvas Application Signatures by Facebook.
· JSON Web Token (JWT) by Yaron Goland and Mike Jones of Microsoft.
In the interest of working towards convergence, this note compares them in detail and proposes resolutions for the differences.
I’m hoping that we can achieve rough consensus that the proposed decisions below or similar ones that we work out together can adequately meet all of our needs for signed JSON tokens. Following a few days of discussions among us and others we believe have pertinent expertise, assuming a consensus emerges, I plan to write a new draft incorporating that consensus and I invite all of you who have contributed to any of the specs below to be listed as contributors or co-authors of the spec.
Your thoughts?
|
Feature |
JSON Simple Sign (JSS) |
JSON Web Token (JWT) |
Proposed Resolution |
||
|
Envelope distinct from payload |
Yes |
Yes |
No |
No |
Yes |
|
Reserved claims defined for use in payload |
Yes |
No |
Yes |
Yes |
Yes – for optional use |
|
Overhead of encoding |
Medium |
High |
Low |
Low |
Low |
|
Signature algorithms supported (recommended marked +, optional marked *) |
HMAC SHA-256, RSA SHA-256 |
HMAC SHA-256, RSA SHA-256 |
HMAC SHA-256 |
HMAC SHA-256, RSA SHA-256+, ECDSA-SHA256+, larger key sizes* |
HMAC SHA-256, RSA SHA-256, ECDSA-SHA256+, larger key sizes* |
|
Signing required |
Yes |
Yes |
Yes |
No |
Yes (but “none” algorithm could be separately defined) |
|
Location of algorithm parameter |
Envelope |
Envelope |
Payload |
Payload |
Envelope |
|
Parameters to algorithm represented distinctly from algorithm family |
No – Fixed sets of algorithm parameters normatively specified |
Yes |
No – Fixed sets of algorithm parameters normatively specified |
No – Fixed sets of algorithm parameters normatively specified |
No – Fixed sets of algorithm parameters normatively specified |
|
Key ID parameter |
Optional in Envelope |
Required in envelope for HMAC SHA-256 |
N/A |
None |
Optional in Envelope |
|
Key location parameter |
Discovery method defined for RSA keys |
Required in envelope for RSA SHA-256 |
N/A |
None |
Optional key location or public key in Envelope; any key discovery in separate specification(s) |
|
Key representation specified |
Yes - Magic Keys for RSA |
Yes – X.509 certificates for RSA SHA-256 |
N/A |
No |
Optional use of X.509 certificates specified; others in separate specs |
|
Type description for envelope |
No |
Required type URI |
No |
No |
Optional using concise representation |
|
Type description for payload |
Optional in envelope |
Optional in Payload |
No |
No |
Optional in Payload |
|
Encoding algorithm |
Base64url with padding |
Base64url without padding |
Base64url without padding |
Base64url without padding |
Base64url without padding |
|
Token representations |
Base64url encodings separated by periods |
Base64url encodings separated by periods, JSON serialization |
Base64url encodings separated by periods |
Base64url encodings separated by periods |
Base64url encodings separated by periods |
|
Multiple signatures |
No (but supported by Magic Signatures) |
Yes |
No |
No |
Not in base spec, but could be defined as an extension |
|
Encryption supported |
No |
In related specification |
No |
No |
In related specification |
-- Mike