Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

From: Esko Dijk <[email-masked]>
Date: Fri, 1 Dec 2017 09:47:52 +0000

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.

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.

3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment 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.

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"?

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 ?

Best regards
Esko Dijk

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: [email-masked]
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked]
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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 Dec 2017 19:52:50 -0600

Hi Esko,

> (Btw sorry for being late responding to this WGLC.)

Thanks for the review; it's always good to have more eyes on the
document.

-Ben

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 6 Dec 2017 13:48:00 +0100

Thanks Esko for your review it is greatly appreciated.

see comments inline

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <[email-masked]> 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.

Good point.
I have created a PR waiting for review by the co-authors

> -> 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.

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.
> 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."

> -> could we clarify where this is added, e.g. say "prepend with the

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"

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.

> 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.
>

---

From: Esko Dijk <[email-masked]>
Date: Wed, 6 Dec 2017 13:48:25 +0000

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.

Best Regards
Esko

From: Samuel Erdtman [mailto:[email-masked]]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

see comments inline

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Entire document:

Good point.

3.1.1 / 3.1.2 / 3.1.3

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

Same as above.

5

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

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

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:[email-masked]<mailto:[email-masked]>] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 8 Dec 2017 13:31:31 +0100

thanks for persisting

See inline

On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk <[email-masked]> wrote:

> > 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:[email-masked]]
> *Sent:* Wednesday, December 6, 2017 13:48
> *To:* Esko Dijk <[email-masked]>
> *Cc:* Benjamin Kaduk <[email-masked]>; [email-masked]
>
> *Subject:* Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29
> November)
>
>
>
> 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

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Dec 2017 13:45:52 +0000

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 <[email-masked]> on behalf of Samuel Erdtman <[email-masked]>
Sent: Friday, December 8, 2017 4:31:31 AM
To: Esko Dijk
Cc: Benjamin Kaduk; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Samuel,

Best Regards

Esko

From: Samuel Erdtman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Cc: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

see comments inline

Dear all,

Entire document:

Good point.

3.1.1 / 3.1.2 / 3.1.3

3.1.4 / 3.1.5 / 3.1.6

Same as above.

5

7.1

9.2.1

Best regards
Esko Dijk

-----Original Message-----
From: Ace [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

-Ben

---

From: Esko Dijk <[email-masked]>
Date: Mon, 11 Dec 2017 11:02:58 +0000

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:[email-masked]]
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk <[email-masked]>; Samuel Erdtman <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

---

From: Jim Schaad <[email-masked]>
Date: Mon, 11 Dec 2017 13:24:26 -0800

Esko,

Whether a generic encode would automatically skip over tags is going to
depend on the data model presented to the user by the parser.  I have worked
with one where the tags are ignored by the data model unless the user
explicitly asks about them.  I have worked with another where the tags are
explicitly modeled in the result of the parser.   There is a node in the
resulting tree that is of node type tag with a value.

Consider the case of something that could be either a string or an url
encoded string.  In this case the only difference in the encoding is the tag
value.   In this case the tag is significant so should not be ignored.  

I agree with Mike that this additional requirement could be misleading.

Jim

From: Ace [mailto:[email-masked]] On Behalf Of Esko Dijk
Sent: Monday, December 11, 2017 3:03 AM
To: Mike Jones <[email-masked]>; Samuel Erdtman
<[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

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:[email-masked]] 
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk <[email-masked] <mailto:[email-masked]> >;
Samuel Erdtman <[email-masked] <mailto:[email-masked]> >
Cc: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 11 Dec 2017 22:58:54 +0100

On Dec 11, 2017, at 12:02, Esko Dijk <[email-masked]> wrote:
> 
> given that a CBOR decoder would normally ignore tags

If you are talking about CBOR tags (I’ve lost the context of the current discussion): 
A generic CBOR decoder would normally present those to the application.
Simply ignoring them would not be very helpful.

Grüße, Carsten

---

From: Esko Dijk <[email-masked]>
Date: Tue, 12 Dec 2017 09:54:05 +0000

With "ignoring" tags I also mean that the decoder presents it to the application; where the application then does not do any _additional_ checks on tags (like e.g. their presence or absence).
Any use of, or checks on tags as needed for the application are of course to be done in the normal way.

In essence my comment is just to enable a way of adding of tags in the future onto today's-tagless-claims, without today's implementations rejecting these future-claims as being malformed/unexpected.  If most think that's already covered by the current text then I'm okay with it.

Esko

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, December 11, 2017 22:59
To: Esko Dijk <[email-masked]>
Cc: Samuel Erdtman <[email-masked]>; Mike Jones <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

Grüße, Carsten