Hello Mike, My intention was to have "no extra code in recipients that verifies absence of tags". I did not intend to propose modification to the CBOR decoder (a generic decoder would skip over i.e. ignore any tags already - which is the right behavior in my view).
I don't see how an additional sentence in the spec "MUST ignore tags" can possibly lead to extra code? A generic CBOR decoder will already skip over any tags. And besides these tags are not present because the spec states they must not be used. So there's nothing a receiver would have to do extra or different. The benefit then seemingly comes for free; and this benefit is the potential usage of tags attached to existing claims, for future versions of the spec. But given that a CBOR decoder would normally ignore tags already, I'm also fine with not changing the text if it is confusing for developers. They might think they need to implement something while the requirement actually asks them *not* to implement something. Most developers would not bother to implement such extra checks anyhow. thanks Esko From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Friday, December 8, 2017 14:46 To: Esko Dijk <esko.d...@philips.com>; Samuel Erdtman <sam...@erdtman.se> Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) 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 ________________________________ 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
