Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

The proposed resolutions have been applied to the -28 draft.  Hopefully this will enable to clear your DISCUSSes.  Thanks again for the careful read!

				-- Mike

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Saturday, October 04, 2014 5:17 PM
> To: Barry Leiba; The IESG
> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-
> token@tools.ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-
> token-27: (with DISCUSS and COMMENT)
> 
> Thanks for your review, Barry.  I'm adding the working group so they’re aware
> of these comments.  At Stephen Farrell's request, I'm responding with "> " line
> prefixes on previous thread content.  I'm also repeating (and in the first case,
> augmenting) my previous responses to the DISCUSS comments in this
> consolidated message.
> 
> > -----Original Message-----
> > From: Barry Leiba [mailto:barryleiba@computer.org]
> > Sent: Wednesday, October 01, 2014 8:54 AM
> > To: The IESG
> > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-
> > token@tools.ietf.org
> > Subject: Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27:
> > (with DISCUSS and COMMENT)
> >
> > Barry Leiba has entered the following ballot position for
> > draft-ietf-oauth-json-web-token-27: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have two points that I'd like to get resolved before happily
> > approving this fine
> > document:
> >
> > -- Section 7.1 --
> >
> > The comparison you specify is as specified in RFC 7159, Section 8.3,
> > which is to "transform the textual representation into sequences of
> > Unicode code units and then perform the comparison numerically, code
> > unit by code unit".  This has no regard for text case, and so it's a case-sensitive
> comparison.
> >
> > And, yet, Sections 5.1 and 5.2 specify that the values of typ and cty
> > are case- insensitive, and specify using upper case as a SHOULD, for
> > "compatibility with legacy implementations".
> >
> > It doesn't seem that "legacy" has anything to do with this: someone
> > conforming to *this* specification will compare the values of typ and
> > cty Unicode-character by Unicode-character, and will fail to match "JWT" with
> "jwt".
> >
> > Is there not a problem here?
> 
> We can update the text to clarify that MIME type comparisons are an exception
> to the “code unit by code unit” comparison rule.  The drafts will also be
> scrutinized for other possible occurrences of exceptions to the default string
> comparison instructions.  Finally, we can add language to 7.1 about "unless
> otherwise noted for a particular kind of string" so that it's clear that there are
> exceptions to the rule.
> 
> > -- Section 10.3.1 --
> >
> > Nice that you cite 2046 for media types, but the *registration* of
> > media types is documented in RFC 6838, and this document doesn't quite
> > conform to that.  The only thing missing in the doc is "Fragment
> > identifier considerations" in the registration template, but 6838 also
> > strongly suggests review of the media-type registration on the
> > media-types mailing list.  Given that this will not get expert review
> > (because it's an IETF-stream RFC), I'd like to ask for an explicit
> > review on the media-types list to make sure that the registration information is
> complete and makes sense.
> 
> Thanks for the 6833 reference.  We’ll use that.  I know that Kathleen already
> initiated the review on the media-types list.
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > -- Abstract --
> >
> >    The suggested pronunciation of JWT is the same as the English word
> >    "jot".
> >
> > I have no objection (well, I do, but it's not for me to say how you
> > want to pronounce it) to having this sentence in the Introduction, but
> > it seems out of place in the Abstract, which is meant to be concise.
> 
> OK - We can remove it from the Abstract.
> 
> > -- Section 4.1 --
> >
> > It appears that all claims defined here are OPTIONAL, and each one
> > says so in its subsection.  Given that they *all* are, it might be
> > useful to say that up front, maybe with a sentence that says, "All
> > claims defined in this section are OPTIONAL to use."  (I don't feel
> > strongly about this; it's just a suggestion, so do with it as you see best.)  See
> also my comment on 10.1.1, below.
> 
> Editorially, we decided to describe the optionality of each claim in the claim
> definition so that when used as a reference without reading the whole thing, the
> optionality will still be obvious to the reader.
> 
> > -- Section 4.1.2 --
> >
> >    The subject value MAY be scoped to be locally
> >    unique in the context of the issuer or MAY be globally unique.
> >
> > Or it MAY be anything else, including not unique at all.  Is that what you mean?
> > Or are these meant to be two options, one of which has to be true?  If
> > so, you need to re-do this, perhaps like this:
> >
> > NEW
> >   The subject value MUST either be globally unique, or be scoped
> >   to be locally unique in the context of the issuer.
> > END
> 
> Your new language matches the intent.  I'll plan to revise accordingly.
> 
> > -- Section 10.1.1 --
> >
> > Given that the descriptions of the claims include a statement that
> > their use is OPTIONAL, should there not be an entry in the table that
> > says whether the claim is OPTIONAL or REQUIRED ?  Or is it the intent
> > that
> > *all* of them always be OPTIONAL ?  Or is it sufficient to have that
> > indication in the reference documentation ?
> 
> What claims are required by applications will be specified by applications.  For
> instance, some applications using JWTs require that the issuer, subject, and
> audience be present.  Therefore, I don't think that adding a table entry would
> help a great deal, and it could even confuse some developers.
> 
> 				-- Mike
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth