Subject: [Ace] WGLC on draft-ietf-ace-cbor-web-token

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Nov 2017 12:24:56 -0500

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Nov 2017 12:26:13 -0500

> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .

We will be treating Hannes' comment about the (lack of) multi-valued
audience as a WGLC comment.  I hope Mike did not need the extra
motivation of the WGLC to go through and make the comparison against JWT :)

-Ben

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Nov 2017 18:33:59 +0100

Just wondering:

Are you aware that this is a second WGLC?  You didn’t mention that.

(And do we really need four weeks for a second WGLC?  Even factoring in the IETF week?)

Grüße, Carsten

> On Nov 1, 2017, at 18:24, Benjamin Kaduk <[email-masked]> wrote:
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Nov 2017 12:41:06 -0500

> Are you aware that this is a second WGLC?  You didn’t mention that.

I was aware, sorry for not mentioning it.  (The first WGLC was on the -04.)

> (And do we really need four weeks for a second WGLC?  Even factoring in the IETF week?)

It spans a US holiday and an IETF meeting, so the extra time seemed warranted
given how many other distractions people may have.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 22 Nov 2017 18:30:51 -0600

Reminder: there is only one week left in this WGLC.

-Ben

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 23 Nov 2017 10:25:18 +0100

Hi ACE,

I have only some nits on the CWT draft (see below).

/Ludwig

========================================================

I'm not sure what the RFC editors prefer as affiliation
(I've seen both):

--
E. Wahlstroem

--  OR
E. Wahlstroem
(no affiliation)
--

===
2. Terminology

In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT 
RECOMMENDED is used in the draft. What is the recommended procedure 
here? It feels like we could remove the other ones.

===

"CWT Claims Set

   The CBOR map that ..."

Why is a map called a set here? I know what is meant, but it sound 
really weird.

===

Sections 3.1.*

The links to sections in JWT point to sections in this draft instead
(at least in the html-ised version of the draft).

See:
https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18

for hints on how to fix this.

===

Figure 1:  Perhaps indicate the CBOR major type number together with the
"Value type" text.

===

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Nov 2017 11:55:46 +0100

Hi Ludwig,

> —

I don’t know what the RFC editor prefers her, but I find “no affiliation” jarring — leaving the space open is much better.

> ===
> 2. Terminology
> 
> In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT RECOMMENDED is used in the draft. What is the recommended procedure here? It feels like we could remove the other ones.

It is usual to include the whole boilerplate (obviously the corrected one, with NOT RECOMMENDED included, in this case).

> ===
> 
> "CWT Claims Set
> 
>  The CBOR map that ..."
> 
> Why is a map called a set here? I know what is meant, but it sound really weird.

Because a claim is a pair of map key and map value, so the whole thing is indeed a set of claims (with the additional restriction that a key can only be used once; hence we need array-valued map values).

(The term “claim" is misleading and wrong here, but that is inherited from JWT.)

> for hints on how to fix this.

Somewhat temporary, but a useful thing to change.

> Figure 1:  Perhaps indicate the CBOR major type number together with the

Or perhaps don’t?  The major type number is something that is internal to the serialization; standards using RFC 7049 should not try to repeat internals of RFC 7049 all over the place.
I’d prefer to use the data model level names as it is specified now.

My editorial comment on this is that this should be a table, not ASCII art.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 23 Nov 2017 13:13:43 +0100

On 2017-11-23 11:55, Carsten Bormann wrote:

>> 
>> Figure 1:  Perhaps indicate the CBOR major type number together
>> with the "Value type" text.
> 
> Or perhaps don’t?  The major type number is something that is
> internal to the serialization; standards using RFC 7049 should not
> try to repeat internals of RFC 7049 all over the place. I’d prefer to
> use the data model level names as it is specified now.

I'll take that as an input to draft-ietf-ace-oauth-authz as well then.

Btw Carsten, can you review that one at some point? I think you input 
would be valuable (we have reviews from a few OAuth experts, but not so 
many from CoRE experts).

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Nov 2017 21:55:09 -0600

> I don’t know what the RFC editor prefers her, but I find “no affiliation” jarring — leaving the space open is much better.

I also sometimes see "Unaffliated".

> It is usual to include the whole boilerplate (obviously the corrected one, with NOT RECOMMENDED included, in this case).

Right, at this point people should be citing BCP 14/RFC 8174.

-Ben

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 28 Nov 2017 13:25:21 +0100

Thanks for the review Ludwig, it is really appreciated.

see inline

> I have only some nits on the CWT draft (see below).

I would prefere the empty space. The xml doc does not contain any text and
when submitting to http://xml2rfc.tools.ietf.org/ I get the empty line.

If co-authors agree I think we need to do something when submitting the new
draft.

> RECOMMENDED is used in the draft. What is the recommended procedure here?
> It feels like we could remove the other ones.
>
> ===
>

I agree with Carsten that the full template should be used. and I agree
with Benjamin that we should use the latest version.
I have created a PR that is waiting for review by co-authors.

> Why is a map called a set here? I know what is meant, but it sound really

I think the is the right way to phrase it.

> for hints on how to fix this.

I have created a PR that is waiting for review by co-authors.

> Figure 1:  Perhaps indicate the CBOR major type number together with the

I agree with Carsten, we have had this discussion before.

I have created a PR changing from ascii art to table (waiting for review by
co-authors)