thanks for persisting See inline
On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk <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] > *Sent:* Wednesday, December 6, 2017 13:48 > *To:* Esko Dijk <esko.d...@philips.com> > *Cc:* Benjamin Kaduk <ka...@mit.edu>; 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> 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] On Behalf Of Benjamin Kaduk > Sent: Thursday, November 23, 2017 01:31 > To: 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 > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > 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 > https://www.ietf.org/mailman/listinfo/ace > > >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
