Another thing has been bugging me since reading the draft yesterday and I'm not sure if this was discussed in the WG or not. There appear to be differences in how a JWT thumbprint is described in the draft. I'd like to see if we can work this out before progress the draft into IETF last call.
The definition is not entirely clear. Section 3 clearly states that the required members of the JWT are part of the thumbprint. Section 3.2.2, although the subtitle makes the point that this is about why optional members are not included, the following sentence appears: The JWK Thumbprint value is a digest of the key value itself -- not of additional data that may also accompany the key. Section 3.4 - Why is this allowed? If it's not in JWT format, it is some other kind of thumbprint. You are essentially creating a JWK to have the key and required members I am assuming, but that's not clear and this text could leave interoperability challenges. Thanks, Kathleen On Mon, Apr 20, 2015 at 3:23 PM, Kathleen Moriarty < [email protected]> wrote: > Hi, > > Thanks for your work on draft-ietf-jose-jwk-thumbprint-04. This is the > last one, right? Great job getting through the JOSE work! > > I read through the draft and have mostly editorial comments that I'd like > to see if we can fix. > > Section 2: > The definition needs some tweaking: > > JWK Thumbprint > The digest value for a key that is the subject of this > specification. > > "the subject of this specification" should not part of text for a > definition. The definition needs to clearly explain the term without > having to read the whole specification. Can you suggest something else? > > Section 4: > > Can you break this sentence into 2: > However, if new JWK members are defined that use non-ASCII member > names, their definitions should specify the exact Unicode code point > sequences used to represent them, particularly in cases in which > Unicode normalization could result in the transformation of one set > of code points into another under any circumstances. > > Can you get rid of the parens around the second sentence? > Use of escaped characters in JWKs for which JWK Thumbprints will be > computed should be avoided. (Use of escaped characters in the hash > input JWKs derived from these original JWKs is prohibited.) > > Can you reword this sentence/paragraph? I had to read it multiple times. > While I understand what you are saying, it could be easier to read. > While there is a natural representation to use for numeric values > that are integers, this specification does not attempt to define a > standard representation for numbers that are not integers or that > contain an exponent component. This is not expected to be a problem > in practice, as the required members of JWK representations are not > expected to use numbers that are not integers. > > General comment, the use of long sentences and frequency of parens make > the draft more difficult to read. > > Thanks! > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
