Requiring extra code in recipients to ignore tags that already must not be present would make them needlessly more complicated and hurt interop. It's virtually certain that many implementations will not include this extra code that should never be executed. We shouldn't put developers in the position of deciding whether to add code for a case that already must not occur.
-- Mike ________________________________ From: Ace <ace-boun...@ietf.org> on behalf of Samuel Erdtman <sam...@erdtman.se> Sent: Friday, December 8, 2017 4:31:31 AM To: Esko Dijk Cc: Benjamin Kaduk; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) thanks for persisting See inline On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk <esko.d...@philips.com<mailto:esko.d...@philips.com>> wrote: Thanks Samuel, I agree with your answers and proposed actions except for the below: > I think the language in section 3 is enough to get robust implementations. > "all claims that are not understood by implementations MUST be ignored." Ignoring a claim is very different from ignoring an unrecognize/unsuitable tag that prefixes a claim. The latter will in fact accept the claim while the former will reject the claim. To get the desired robustness and future extendibility, and make tags useful for existing claims, an implementation must ignore the unrecognized tag – but not the claim. (Assuming any cases where the receiver should understand the claim but a future-version sender has added an additional future-version tag to it.) What this can achieve is keep using ‘old’ version claims while augmenting these with ‘new version’ semantics by use of tags, in a future version of the specification. Besides with current Section 3 & 5 language one claim parser #1 may still consider an “exp” claim as “understood” because it ignores any tags for it, while parser #2 may reject that “exp” claim because it sees a tag that is not 1. While parser #3 may reject an “exp” claim even with a tag 1 because it considers it out of scope of the spec (which says sender MUST NOT use this tag hence any tag usage is not according to spec so not understood.). In a way this issue is similar to the archetypical spec requirement of “sender MUST put 0s in this field and a receiver MUST ignore the value of this field”. Both are needed. I have added created a PR with some text to make this more specific. please have a look at https://github.com/erwah/ietf/pull/74 Best Regards Esko From: Samuel Erdtman [mailto:sam...@erdtman.se<mailto:sam...@erdtman.se>] Sent: Wednesday, December 6, 2017 13:48 To: Esko Dijk <esko.d...@philips.com<mailto:esko.d...@philips.com>> Cc: Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>>; ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thanks Esko for your review it is greatly appreciated. see comments inline On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <esko.d...@philips.com<mailto:esko.d...@philips.com>> wrote: Dear all, Overall the document looks in good shape to go forward if the earlier mentioned issue of multiple values for "audience" (reported by Hannes) is addressed; and the below issue I see for Section 5. Other comments are minor. (Btw sorry for being late responding to this WGLC.) My review comments to specific sections: Entire document: Replace "binary string" by "byte string". The latter is the name used in RFC 7049. Good point. I have created a PR waiting for review by the co-authors 3.1.1 / 3.1.2 / 3.1.3 "except that the value is of type StringOrURI" -> May be slightly confusing to readers, since JWT also has StringOrURI named type. So it seemingly says "don't use StringOrURI, but use StringOrURI." This is most likely intended, as in "don't use JWT StringOrURI, but use our CWT StringOrURI". So also fine if we leave this formulation in, but it could still cause some confusion. I see your point, but I don´t think it will be an issue. JWT is in JSON context and CWT is in CBOR context so whenever string is refereed to in CWT the reader should think CBOR string and vice verse for JWT. If you don´t have a strong opinion here or a great suggestion for a new name I would like to keep it as it is. 3.1.4 / 3.1.5 / 3.1.6 "except that the value is of type NumericDate" -> same comment as above. Same as above. 5 Text states the sender MUST NOT use a tag, but future specs may introduce tags for claim values. Then it seems required to also include some text about how a receiver implementing the *current* version of CWT should handle tags for claim values, which may come from a sender implementing a future version of CWT. E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim value." That should help robustness and future extendibility. E.g. we don't want receivers of a CWT to go check if tags are present and reject the CWT if a Tag is found. I think the language in section 3 is enough to get robust implementations. "all claims that are not understood by implementations MUST be ignored." 7.1 Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the appropriate COSE CBOR tag" -> could we clarify where this is added, e.g. say "prepend with the matching COSE CBOR tag"? I think adding the tag in itself has this semantic. But I have created a PR with the change, so that my co-authors can consider it. 9.2.1 "Applications that use this media type: IoT applications sending security tokens over HTTP(S) and other transports" -> can already mention CoAP/CoAPs here ? It is not obvious that we should mention CoAP(S) here since the media type is for HTTP(S) and not CoAP(S) and it does state that "and other transports". For CoAP(S) we register the CoAP Content-Format that maps to this media type. Best regards Esko Dijk -----Original Message----- From: Ace [mailto:ace-boun...@ietf.org<mailto:ace-boun...@ietf.org>] On Behalf Of Benjamin Kaduk Sent: Thursday, November 23, 2017 01:31 To: ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Reminder: there is only one week left in this WGLC. -Ben On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. > > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > Thanks, > > Ben and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org<mailto:Ace@ietf.org> > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email. _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
