Hi Prateek,
Thanks for taking the time to send in these comments. I am sending you this to
describe the changes that were made in response to your comments (mostly in -13
but also a few in -18). See individual responses inline.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Prateek Mishra
Sent: Wednesday, August 21, 2013 4:51 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] WGLC on JSON Web Token (JWT)
1) As a JWT is always an instance of JWE or JWS, I am not sure why there is a
need for the the materials found in Section 5, para 1 (these are also found in
the JWE and JWS draft specifications). It could simply be removed from the
draft.
There's a stylistic tension between saying things in exactly one place and
making each document easier to read without constantly having to flip back and
forth between them. In this case, I believe that the small amount of
duplication aids developers who might not recursively read everything
referenced in full detail.
2) Why do we need both a "typ" claim and a "typ" header name? Need they have
some relationship to each other?
Isn't this also covered by Section 5.3?
The "typ" claim was removed as part of the JOSE change to use MIME type names
for "typ" and "cty" header parameter values.
3) The materials in Section 5.3 could be simplified further.
Why should the use of claims as header parameters be restricted to the case
where the JWT=JWE; what about the encrypt then sign (symmetric) use-case? I see
no issue in allowing this feature with a JWT of any type.
As written, the specs actually already allow the header to be extended with any
parameters, as needed by applications. Replicating encrypted claims as
unencrypted header parameter values is only one such permitted usage.
The last paragraph of Section 5.3 ("This specification reserves the iss
(issuer), sub (subject),....") seems to be an instance of the
previous paragraph. If claims are allowed in the header, then iss (issuer), sub
(subject) are trivially allowed, right? I couldn't find any additional
information in this last paragraph.
This text is referring to the fact that these three claims are registered in
the IANA JSON Web Signature and Encryption Header Parameters registry for use
as header parameters. I clarified this by adding a section number reference.
Finally, do we need "SHOULD verify that their values are identical" - given
that this matter is left upto applications, couldnt they choose to verify only
a certain relationship between the corresponding values (e.g., header carries
hash of value, JWT carries the (large) complete value)? Can this be weakened
to "SHOULD verify that their values have an appropriate (application-defined)
relationship. In many instances, applications may want to ensure that they are
identical".
Agreed. I added a qualifying clause saying that "the application receiving
them SHOULD verify that their values are identical, unless the application
defines other specific processing rules for these Claims".
4) Section 8 -
am I correct in reading this as: all conforming JWT implementations MUST
implement JWS and MAY implement JWE?
At least thats what I understood from the last paragraph ("if an implementation
provides encryption capabilities...").
Correct
- prateek
Hi all,
this is a working group last call for the JSON Web Token (JWT).
Here is the document:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-11
Please send you comments to the OAuth mailing list by August 21, 2013.
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
