Thanks Jim! Se comments inline
On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad <[email protected]> wrote: > Comments on this version of the draft. > > Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR > tag at this point > In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full CWT if transport layer cannot indicate that this is a CWT. In this case you would want first the COSE tag and then the CWT tag this is described in section 6. We asked Carsten about this before we added the text so it should be okay. In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell. > > Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR > object. > Good catch I´ll fix, Issue create for now. > > Appendix A.3 - I was unable to reproduce the example. I assume that this > means that a deterministic signature algorithm is not being used. While a > verifier cannot tell if one is being used, the COSE document does strongly > suggest that one be used. Additionally, it helps in testing if one is used > so that a signature creator can be more easily tested. > Correct I have not used a deterministic signing algorithm. I have used COSE-JAVA to create the examples, is it possible to configure that implementation to generate deterministic ECDSA signatures? When working with my JS implementation I have noticed that support for deterministic ECDSA implementations are hard to find. > > Appendix A.5 - I was unable to reproduce the example. Specially the tag > value does not match with the one that I compute. > That is bad. but apart from the tag it looks good? > > Appendix A.6 - I did not try to reproduce given that a) I would not > generate the same signature and b) the example A.5 failed. > See comments above. > > > Minor: > > In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE > Good catch. However I think it should be s/In COSE/In CWT/, I have created an issue to fix this. > > In section 2: s/CBOR encoded claim key/CBOR claim key/ > * I am unsure why you would think that encoded is needed here. > * Should this be CWT rather than CBOR? > * Why is section 3.1 "Claim Names" rather than "Claim Keys" > I have created an issue to address this. I think the name of section 3.1 is legacy from JWT where the equivalent section is called "Registered Claim Names" I would like to change the name to just "Registered Claims" since it is not just he names or the key that is registered also value type. > > In section 2: Is there a reason not to define CWT claim value in this > section > Sorry I´m not following, could you please explain a bit more`? > In section 3.1.1 and on - the following might be considered cleaner > s/except that the format MUST be a/except that the value MUST be of type/ > I have created an issue for this to be considered > > Section 9.1.2 - I would suggest assigning a name to the reserved entry > I have created an issue for this to be considered > > -----Original Message----- > From: Ace [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Monday, June 5, 2017 6:27 PM > To: [email protected] > Cc: [email protected] > Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication and Authorization for > Constrained Environments of the IETF. > > Title : CBOR Web Token (CWT) > Authors : Michael B. Jones > Erik Wahlström > Samuel Erdtman > Hannes Tschofenig > Filename : draft-ietf-ace-cbor-web-token-05.txt > Pages : 23 > Date : 2017-06-05 > > Abstract: > CBOR Web Token (CWT) is a compact means of representing claims to be > transferred between two parties. The claims in a CWT are encoded in > the Concise Binary Object Representation (CBOR) and CBOR Object > Signing and Encryption (COSE) is used for added application layer > security protection. A claim is a piece of information asserted > about a subject and is represented as a name/value pair consisting of > a claim name and a claim value. CWT is derived from JSON Web Token > (JWT), but uses CBOR rather than JSON. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-05 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
