Thanks for your useful comments, Brian. See my replies inline.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Brian
Campbell
Sent: Friday, November 01, 2013 12:53 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email protected]
Subject: Re: [OAUTH-WG] Next Steps for the JSON Web Token Document
I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.html
from Hannes noting reviews on draft-ietf-oauth-json-web-token and was surprised
that mine wasn't included. So I went looking for it and apparently I didn't
actually send it to the list. But I did find it and am including what I wrote
and tried but failed to send back in September. Sorry about that.
And here it s:
Below are my review comments on the JSON Web Token Document that I (had
forgotten until reminded by Hannes yesterday) committed to reviewing at the
meeting in Berlin.
Review of draft-ietf-oauth-json-web-token-11:
* The sentence about the suggested pronunciation being 'jot' is in both the
intro and the abstract. Seems like just once would be sufficient.
Yes, but some people start reading with the abstract and some start reading
with the introduction. I want them to read that whichever place they start.
So I didn't change this.
* Should "Base64url Encoding" in the Terminology section also mention the
omission/prohibition of line wrapping?
Good catch. I've added this, both here and in the JWS spec, which defines it
for JOSE.
* References to sections or appendices in other documents often don't have the
correct href value. For example, "Base64url Encoding" in the Terminology
section has this problem for Section 3.2, which should point to RFC 4648 and
Appendix C, which should go to JWS but both refer to the local document. There
are many other instances of the same issue. I assume this is due to some tool
in the xml2rfc or I-D upload process (and I know I have it in some of the
drafts I author) but is this the kind of thing that the RFC editor will take
care of?
That's something the IETF post-processing tools are doing and getting wrong.
You'll notice that this problem doesn't exist in the HTML version that's
directly generated by xml2rfc that's posted at
http://self-issued.info/docs/draft-ietf-oauth-json-web-token-17.html, for
instance. So yes, this is in the RFC Editor domain.
* I continue to struggle to understand how the type and content type Header
parameters and the type claim can or will be used in a meaningful and reliable
way. I can't help but wonder if it couldn't be simplified. For example. what
if we only had the cty header and defined a cty value for a JWT Claims Set -
couldn't all the same things be conveyed?
As described in the JOSE specs that define them, "typ" is the type of the
entire object, whereas "cty" is the type of the message contained in the JWS or
JWE. Both are now MIME type values. "cty" is used by JWTs in the specific way
specified whereas "typ" can be used as needed by applications using JWTs.
* There are a number of the reserved claims that say the use of the claim is
OPTIONAL while also stating that the "JWT MUST be rejected" if some condition
about the claim doesn't hold. There seems to be some potential ambiguity here
regarding whether (in the absence of tighter context-dependent requirements,
which is what generalized JWT libraries need to be built for) the optionality
applies only to the producer or also to the consumer of a JWT. My guess is that
the claims are optional to include for the producer but, if they are present,
they must be validated by the consumer and the JWT must be rejected if whatever
condition isn't satisfied. Do I have that right? Regardless, I think there is
some ambiguity as currently written that should be clarified.
Many of these have been revised since WGLC. The only "MUST be rejected"
remaining is for the audience claim, in which I've qualified the "MUST be
rejected" with "if this claim is present" - clearing up this ambiguity.
Note that some of these comments relate to or even apply directly to JWS and
JWE as well. Which I suppose underscores the point James made a while ago about
progressing this document so far ahead of the JOSE drafts.
[https://mail.google.com/mail/u/0/images/cleardot.gif]
There was one comment - the one about base64url encoding - that also required a
coordinated change in JWS, hence the publication of the -23 JOSE drafts.
On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo)
<[email protected]<mailto:[email protected]>> wrote:
Hi again,
I also checked the minutes from IETF#87 regarding the JWT and here are the
action items:
** I issued a WGLC, as discussed during the meeting:
http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html
** We got some reviews from James, and Prateek. Thanks, guys!
Here are the reviews:
http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html (James)
http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html (Prateek)
During the meeting a few others, namely Torsten, Karen, Paul Hoffman, and
Brian volunteered to provide their review comments. Please send your review to
the list.
** I will have to do my shepherd write-up as well.
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
