Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
RFC 8747

Note: This ballot was opened for revision 09 and is now closed.

Benjamin Kaduk Yes

(Alexey Melnikov) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-10-30 for -09)
No email
send info
Thank you -- this was clear enough that even I could understand it...

(Mirja Kühlewind) No Objection

Comment (2019-10-25 for -09)
I would like to discuss one point with the IESG, however, not raising my ballot to "discuss" as I believe we can conclude quickly and this is not a major problem anyway. 

So it seems to become more common to not only have expert review but also post a registration request on a public list and wait for a couple of weeks for comments. While I myself am uncertain if that is a good or bad practice (maybe also depends on the protocol), I would like to discuss this part in the IANA section:

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to Register CWT Confirmation
   Method: example").  Registration requests that are undetermined for a
   period longer than 21 days can be brought to the IESG's attention
   (using the iesg@ietf.org mailing list) for resolution.

I would think that, no matter what, registration request should be directed at IANA (and they would then post or forward to a mailing list and/or experts; or alternatively the experts can post than on the mailing list). I guess IANA would need to provide feedback here on what they prefer. However, for raising problems, of course everybody can always bring any problem to the IESG, but I think the first point of contact should also be IANA here. And then if no resolution can be find quickly for whatever reason, I would think that it's rather IANA that will bring this to the IESG (than the requesters directly).

Barry Leiba No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2019-10-28 for -09)
Thanks for the work everyone put into defining this mechanism. I have one
very minor comment that the authors may wish to take into account.

§3.3:

>     /alg/ 3 : /HMAC256//256/ 5,

This use of "//" seems problematic, given RFC 8610's vague reservation of this
sequence for some kind of "comment to end of line" designation:

   (There are currently no end-of-line comments.  If we want to add
   them, "//" sounds like a reasonable delimiter given that we already
   use slashes for comments, but we could also go, for example,
   for "#".)

Given the potential ambiguity introduced by RFC 8610, perhaps
consider some other syntax here instead of "//".

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-10-30 for -09)
Thank you for the work put into this document. The document is easy to read. I only one nit in section 3 and feel free to ignore all of it: While "sub" is explained as being the "subject", nothing is written about "iss" claim on the first time this term is used, it is only explained the 2nd time.

For my IESG colleagues, I second Mirja's comment about adding a IANA registry entry based on email.

Regards,

-éric

Magnus Westerlund No Objection

Roman Danyliw Recuse

Comment (2019-10-24 for -09)
No email
send info
Former WG chair and shepherd of this draft.