Subject: [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Sat, 14 Dec 2019 14:46:05 -0800

Reviewer: Elwyn Davies
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-oauth-params-06
Reviewer: Elwyn Davies
Review Date: 2019-12-14
IETF LC End Date: 2019-12-13
IESG Telechat date: Not scheduled for a telechat

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.

Document: draft-ietf-ace-oauth-params-06
Reviewer: Elwyn Davies
Review Date: 2019/12/14
IETF LC End Date: 2019/2/13
IESG Telechat date: (if known) N/A

Summary: Not ready.  In particular there seems to be some doubt as to whether
the definitions in this document are actually stable - or alternatively that it
lacks a versioning mechanism to cope with changes that the might be.

Major issues:
Dealing with possible updates to items defined here:
In s1 the following appears:

    These parameters and claims can also be used in other contexts, and may
    need to be updated to align them with ongoing OAuth work. Therefore, these
    parameters and claims have been put into a dedicated document, to
    facilitate their use and any potential updates in a manner independent of
    [I-D.ietf-ace-oauth-authz].

I am unclear whether this implies that it is intended that these potential
updates would alter the definitions here after they have been standardized or
alternatively that the standardization of this document should be delayed until
the alternative usage is defined.  If the first case applies, I do not see any
versioning mechanism that would allow early implementations to cope with later
updates of the items defined here.  In the second case, I have to ask myself
why this document has been submitted for standardization before the usages have
stabilized.

Minor issues:
ss3.1, 3.2 and 4.1:  The COSE_Key type 'EC' used in several kty fields is not
defined.  I assume it should be 'EC2'.

ss3.1, 3.2 and 4.1:  Does it matter that the definitions of the x and y
parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as
'b64' in this document?  I am very much not an expert here.

s6: This section starts with 'If CBOR is used...': The main ACE draft
draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR
encodings of payloads, although CBOR is recommended.  This is not made explicit
in this addition to that specification and the use of CBOR diagnostic
representation and the prominence of COSE_Key items could make it appear up
until s6 that this specification is intended just for CBOR encoding.  A few
words at the beginning would clarify the dual alternatives.

Nits/editorial comments:
General: s/e.g./e.g.,/ (3 places)

Abstract, 2nd sentence: s/whishes/wishes/

Abstract: Need to expand AS and RS.

s2:  RS, AS and (probably) various other terms are defined in RFC 6749 and need
to be expanded on  first use.  Adding something like the para from
draft-ietf-ace-oauth-authz would solve this (except for the abstract).

    Terminology for entities in the architecture is defined in OAuth 2.0
    [RFC6749] such as client (C), resource server (RS), and authorization
    server (AS).s2, para 3: Need to expand CoAP on first use.

s3:  This section needs a reference to RFC 8152 for the specification of the
CWT COSE_Key item that is used extensively.

s3/s4: Some introductory text for each section is desirable.

s3.1, para 2 (definition of req_cnf):: Possibly add a note that the
recommendation against symmetric keys implies currently kty being 'Symmetric'. 
Will it ever be anything else?

s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans
the following

   The COSE_Key MUST contain the required key members for a COSE_Key of that
   key type and MAY contain other COSE_Key members, including the "kid" (Key
   ID) member.

   The "COSE_Key" member MAY also be used for a COSE_Key representing a
   symmetric key, provided that the CWT is encrypted so that the key is not
   revealed to unintended parties. The means of encrypting a CWT is explained
   in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be
   encrypted as described in Section 3.3.

These riders probably apply to all the subsectons of s3 and to s4.1 and could
be included in the currently empty main section text.

s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other
uses do not hyphenate and RPK needs to be expanded.
   s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 17 Dec 2019 17:52:50 +0100

Hello Elwyn,

thank you for your review. Comments inline.

/Ludwig

> why this document has been submitted for standardization before the usages have

The intention with this document was to place certain parameters
(req_cnf, cnf, rs_cnf) needed for draft-ietf-ace-oauth-authz into a
separate document, that could be updated or obsoleted by other drafts
without obsoleting or updating draft-ietf-ace-oauth-authz.

This is mainly due to some work in the OAuth WG which has been running
in parallel, especially
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution.

Since this is not a high priority item for OAuth (the draft named above
has expired), the feeling in ACE was (@ACE please correct me if I
misrepresent) that going forward with this document was a good
compromise to get these parameters standardized, while causing minimal
breakage if OAuth at some later point finalized the pop key distribution
work.

> defined.  I assume it should be 'EC2'.
Correct, will fix

> 'b64' in this document?  I am very much not an expert here.

This is just a matter of the diagnostic representation used here for
human readability. On the wire this will be the same binary string.

Note that the hex encoding h'....' renders a much longer string than the
Base64 encoding b64'...' so I prefer b64 for readability.
> words at the beginning would clarify the dual alternatives.
I will add a clarification. The intention is to cover both JSON and CBOR.

> Nits/editorial comments:

Will fix.

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

---

From: elwynd <[email-masked]>
Date: Thu, 19 Dec 2019 20:23:50 +0000

Hi, Ludwig.Thanks for the prompt response.Regarding he major issue, I understand what the intention of the split was, but as far as early implementations are concerned, there is no such thing as a 'minimal breakage'; unless there is some cunning mechanism in the basic ace-oauth-authz protocol, changes to the structure of the items defined here will break the protocol.  One possibility that I could see is the addition of extra keys in the COSE_Key dictionary structure: In this case you could add some extra words (in the ace-oauth-authz document) to indicate that unrecognized keys should be ignored.  This is associated with the editorial comments I made about s3.1 that would allow any other keys to be present in the COSE_Key object structure.  Similarly, the obects defined here are effectively JSON/CBOR dictionaries.  The changes could be accomodated by adding comments in ace-oauth that extra keys in the items defined would be ignored.  In my opinion, it would be best to remove the comments about possible changes and just state that they have been separated out because they might be used in other contexts.  The possible 'changes to the definitions' issue is just a matter of 'institutional memory'.  If there is some mechanism, such as I mentioned above, to accommodate changes without neeeding an update to the ace-oauth-authz (or other protocols using these items), this should be explained.Regarding the h vs b64 representations, since they are only examples (and the strings are essentially arbitrary as the actual keys aren't in the document), I'd be inclined to put in h representations to avoid my question arisng.   Otherwise I think we are done.Cheers and best wishes for the Festive Season,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <[email-masked]> Date: 17/12/2019  16:53  (GMT+00:00) To: [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: Re: [Gen-art] [Ace] Genart last call review of
  draft-ietf-ace-oauth-params-06 Hello Elwyn,thank you for your review. Comments inline./LudwigOn 2019-12-14 23:46, Elwyn Davies via Datatracker wrote:> Reviewer: Elwyn Davies> Review result: Not Ready>> I am the assigned Gen-ART reviewer for this draft. The General Area> Review Team (Gen-ART) reviews all IETF documents being processed> by the IESG for the IETF Chair.  Please treat these comments just> like any other last call comments.>> For more information, please see the FAQ at>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.>> Document: draft-ietf-ace-oauth-params-06> Reviewer: Elwyn Davies> Review Date: 2019-12-14> IETF LC End Date: 2019-12-13> IESG Telechat date: Not scheduled for a telechat>> I am the assigned Gen-ART reviewer for this draft. The General Area> Review Team (Gen-ART) reviews all IETF documents being processed> by the IESG for the IETF Chair.  Please treat these comments just> like any other last call comments.>> For more information, please see the FAQ at>> <">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.>> Document: draft-ietf-ace-oauth-params-06> Reviewer: Elwyn Davies> Review Date: 2019/12/14> IETF LC End Date: 2019/2/13> IESG Telechat date: (if known) N/A>> Summary: Not ready.  In particular there seems to be some doubt as to whether> the definitions in this document are actually stable - or alternatively that it> lacks a versioning mechanism to cope with changes that the might be.>> Major issues:> Dealing with possible updates to items defined here:> In s1 the following appears:>>      These parameters and claims can also be used in other contexts, and may>      need to be updated to align them with ongoing OAuth work. Therefore, these>      parameters and claims have been put into a dedicated document, to>      facilitate their use and any potential updates in a manner independent of>      [I-D.ietf-ace-oauth-authz].>> I am unclear whether this implies that it is intended that these potential> updates would alter the definitions here after they have been standardized or> alternatively that the standardization of this document should be delayed until> the alternative usage is defined.  If the first case applies, I do not see any> versioning mechanism that would allow early implementations to cope with later> updates of the items defined here.  In the second case, I have to ask myself> why this document has been submitted for standardization before the usages have> stabilized.>The intention with this document was to place certain parameters(req_cnf, cnf, rs_cnf) needed for draft-ietf-ace-oauth-authz into aseparate document, that could be updated or obsoleted by other draftswithout obsoleting or updating draft-ietf-ace-oauth-authz.This is mainly due to some work in the OAuth WG which has been runningin parallel, especiallyhttps://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution.Since this is not a high priority item for OAuth (the draft named abovehas expired), the feeling in ACE was (@ACE please correct me if Imisrepresent) that going forward with this document was a goodcompromise to get these parameters standardized, while causing minimalbreakage if OAuth at some later point finalized the pop key distributionwork.> Minor issues:> ss3.1, 3.2 and 4.1:  The COSE_Key type 'EC' used in several kty fields is not> defined.  I assume it should be 'EC2'.>Correct, will fix> ss3.1, 3.2 and 4.1:  Does it matter that the definitions of the x and y> parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as> 'b64' in this document?  I am very much not an expert here.This is just a matter of the diagnostic representation used here forhuman readability. On the wire this will be the same binary string.Note that the hex encoding h'....' renders a much longer string than theBase64 encoding b64'...' so I prefer b64 for readability.>> s6: This section starts with 'If CBOR is used...': The main ACE draft> draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR> encodings of payloads, although CBOR is recommended.  This is not made explicit> in this addition to that specification and the use of CBOR diagnostic> representation and the prominence of COSE_Key items could make it appear up> until s6 that this specification is intended just for CBOR encoding.  A few> words at the beginning would clarify the dual alternatives.>I will add a clarification. The intention is to cover both JSON and CBOR.> Nits/editorial comments:Will fix.> General: s/e.g./e.g.,/ (3 places)>> Abstract, 2nd sentence: s/whishes/wishes/>> Abstract: Need to expand AS and RS.>> s2:  RS, AS and (probably) various other terms are defined in RFC 6749 and need> to be expanded on  first use.  Adding something like the para from> draft-ietf-ace-oauth-authz would solve this (except for the abstract).>>      Terminology for entities in the architecture is defined in OAuth 2.0>      [RFC6749] such as client (C), resource server (RS), and authorization>      server (AS).s2, para 3: Need to expand CoAP on first use.>> s3:  This section needs a reference to RFC 8152 for the specification of the> CWT COSE_Key item that is used extensively.>> s3/s4: Some introductory text for each section is desirable.>> s3.1, para 2 (definition of req_cnf):: Possibly add a note that the> recommendation against symmetric keys implies currently kty being 'Symmetric'.> Will it ever be anything else?>> s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans> the following>>     The COSE_Key MUST contain the required key members for a COSE_Key of that>     key type and MAY contain other COSE_Key members, including the "kid" (Key>     ID) member.>>     The "COSE_Key" member MAY also be used for a COSE_Key representing a>     symmetric key, provided that the CWT is encrypted so that the key is not>     revealed to unintended parties. The means of encrypting a CWT is explained>     in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be>     encrypted as described in Section 3.3.>> These riders probably apply to all the subsectons of s3 and to s4.1 and could> be included in the currently empty main section text.>> s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other> uses do not hyphenate and RPK needs to be expanded.>     s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/>>> _______________________________________________> Ace mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/ace>_______________________________________________Gen-art mailing [email-masked]://www.ietf.org/mailman/listinfo/gen-art

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 21 Dec 2019 13:22:29 +0100

On 2019-12-19 21:23, elwynd wrote:
> Hi, Ludwig.
>
> Thanks for the prompt response.
>
> Regarding he major issue, I understand what the intention of the split
> was, but as far as early implementations are concerned, there is no such
> thing as a 'minimal breakage'; unless there is some cunning mechanism in
> the basic ace-oauth-authz protocol, changes to the structure of the
> items defined here will break the protocol.  One possibility that I
> could see is the addition of extra keys in the COSE_Key dictionary
> structure: In this case you could add some extra words (in the
> ace-oauth-authz document) to indicate that unrecognized keys should be
> ignored.  This is associated with the editorial comments I made about
> s3.1 that would allow any other keys to be present in the COSE_Key
> object structure.  Similarly, the obects defined here are effectively
> JSON/CBOR dictionaries.  The changes could be accomodated by adding
> comments in ace-oauth that extra keys in the items defined would be
> ignored.
>
> In my opinion, it would be best to remove the comments about possible
> changes and just state that they have been separated out because they
> might be used in other contexts.  The possible 'changes to the
> definitions' issue is just a matter of 'institutional memory'.  If there
> is some mechanism, such as I mentioned above, to accommodate changes
> without neeeding an update to the ace-oauth-authz (or other protocols
> using these items), this should be explained.

I have submitted an updated draft (-08) that removes the comments about
possible changes. Does this address your major issue?

>
> Regarding the h vs b64 representations, since they are only examples
> (and the strings are essentially arbitrary as the actual keys aren't in
> the document), I'd be inclined to put in h representations to avoid my
> question arisng.

In my newly submitted draft all the b64 representations have been
replaced by equivalent h representations.

Note that none of these strings are arbitrary, since they do parse to
actual keys. The abbreviated b64 strings representing tokens obviously
do not parse as such, but come from the actual binary representation of
tokens.

Happy holidays,

Ludwig

---

From: elwynd <[email-masked]>
Date: Sat, 21 Dec 2019 13:50:00 +0000

Hi, Ludwig.Yes, -08 addresses the two points noted below... unfortunately you didn't fix the various nits and the other minor issues as you indicated you were intending to in your initial response (EC => EC2, etc).Enjoy the holidays!Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <[email-masked]> Date: 21/12/2019  12:22  (GMT+00:00) To: elwynd <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: Re: [Gen-art] [Ace] Genart last call review of
  draft-ietf-ace-oauth-params-06 On 2019-12-19 21:23, elwynd wrote:> Hi, Ludwig.>> Thanks for the prompt response.>> Regarding he major issue, I understand what the intention of the split> was, but as far as early implementations are concerned, there is no such> thing as a 'minimal breakage'; unless there is some cunning mechanism in> the basic ace-oauth-authz protocol, changes to the structure of the> items defined here will break the protocol.  One possibility that I> could see is the addition of extra keys in the COSE_Key dictionary> structure: In this case you could add some extra words (in the> ace-oauth-authz document) to indicate that unrecognized keys should be> ignored.  This is associated with the editorial comments I made about> s3.1 that would allow any other keys to be present in the COSE_Key> object structure.  Similarly, the obects defined here are effectively> JSON/CBOR dictionaries.  The changes could be accomodated by adding> comments in ace-oauth that extra keys in the items defined would be> ignored.>> In my opinion, it would be best to remove the comments about possible> changes and just state that they have been separated out because they> might be used in other contexts.  The possible 'changes to the> definitions' issue is just a matter of 'institutional memory'.  If there> is some mechanism, such as I mentioned above, to accommodate changes> without neeeding an update to the ace-oauth-authz (or other protocols> using these items), this should be explained.I have submitted an updated draft (-08) that removes the comments aboutpossible changes. Does this address your major issue?>> Regarding the h vs b64 representations, since they are only examples> (and the strings are essentially arbitrary as the actual keys aren't in> the document), I'd be inclined to put in h representations to avoid my> question arisng.In my newly submitted draft all the b64 representations have beenreplaced by equivalent h representations.Note that none of these strings are arbitrary, since they do parse toactual keys. The abbreviated b64 strings representing tokens obviouslydo not parse as such, but come from the actual binary representation oftokens.Happy holidays,Ludwig

---

From: Ludwig Seitz <[email-masked]>
Date: Sun, 22 Dec 2019 13:35:59 +0100

Hello Elwyn,

I have now submitted -09 to fix the minor issues and nits, which I
forgot in my -08.

Comments inline.

Regards,

Ludwig

> defined.  I assume it should be 'EC2'.
Fixed

> 'b64' in this document?  I am very much not an expert here.
All changed to 'h' encoding

> words at the beginning would clarify the dual alternatives.
Added a paragraph in the introduction to clarify this.

> General: s/e.g./e.g.,/ (3 places)
Fixed

> Abstract, 2nd sentence: s/whishes/wishes/
Fixed
> draft-ietf-ace-oauth-authz would solve this (except for the abstract).
I added a sentence in the terminology section to clarify this. However
note that it already said (in -06):

    Readers are assumed to be familiar with the terminology from
    [I-D.ietf-ace-oauth-authz].

Which included the terms AS and RS.

> CWT COSE_Key item that is used extensively.

Done

> s3/s4: Some introductory text for each section is desirable.
Done

> Will it ever be anything else?
Done

> be included in the currently empty main section text.

Here I disagree. The text explicitly refers to
draft-ietf-ace-cwt-proof-of-possession, saying that the contents of the
'cnf', 'req_cnf' and 'rs_cnf' parameters use the syntax of the 'cnf'
claim from section 3.1 of draft-ietf-ace-cwt-proof-of-possession.
The requirements in section 3.2 draft-ietf-ace-cwt-proof-of-possession
follow from the use of the definitions in 3.1.

I don't see the value of reiterating such a long text from that document
here, when an explicit reference is already given.

>     s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/
Done

---

From: elwynd <[email-masked]>
Date: Sun, 22 Dec 2019 18:27:22 +0000

Hi, Ludwig.Having had another look at section 3.1 of draft-ietf-ace-cwt-proof-of-possession, technically the rules about which keys have to be present are not part of the syntax of the cnf claim.  The point can be covered by changing '"syntax of the 'cnf' claim"to "syntax and semantics of the 'cnf' claim"in each case.However, the second look threw up another point:  Figure 2 in s3.2 gives a Symetric key example  - I think this should use an Encrypted_COSE_Key (or Encrypted_COSE_Key0) as described in section 3.3 of draft-ietf-ace-cwt-proof-of-possession.Otherwise I think we are done.Eventually we will get to Christmas!  Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <[email-masked]> Date: 22/12/2019  12:36  (GMT+00:00) To: Elwyn Davies <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: Re: [Gen-art] [Ace] Genart last call review of
  draft-ietf-ace-oauth-params-06 Hello Elwyn,I have now submitted -09 to fix the minor issues and nits, which Iforgot in my -08.Comments inline.Regards,LudwigOn 2019-12-14 23:46, Elwyn Davies via Datatracker wrote:<deleted>> s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans> the following>>     The COSE_Key MUST contain the required key members for a COSE_Key of that>     key type and MAY contain other COSE_Key members, including the "kid" (Key>     ID) member.>>     The "COSE_Key" member MAY also be used for a COSE_Key representing a>     symmetric key, provided that the CWT is encrypted so that the key is not>     revealed to unintended parties. The means of encrypting a CWT is explained>     in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be>     encrypted as described in Section 3.3.>> These riders probably apply to all the subsectons of s3 and to s4.1 and could> be included in the currently empty main section text.>Here I disagree. The text explicitly refers todraft-ietf-ace-cwt-proof-of-possession, saying that the contents of the'cnf', 'req_cnf' and 'rs_cnf' parameters use the syntax of the 'cnf'claim from section 3.1 of draft-ietf-ace-cwt-proof-of-possession.The requirements in section 3.2 draft-ietf-ace-cwt-proof-of-possessionfollow from the use of the definitions in 3.1.I don't see the value of reiterating such a long text from that documenthere, when an explicit reference is already given._______________________________________________Gen-art mailing [email-masked]://www.ietf.org/mailman/listinfo/gen-art

---

From: Jim Schaad <[email-masked]>
Date: Mon, 23 Dec 2019 11:49:28 -0800

From: Ace <[email-masked]> On Behalf Of Seitz Ludwig
Sent: Sunday, December 22, 2019 11:52 PM
To: 'elwynd' <[email-masked]>; Ludwig Seitz <[email-masked]>; Elwyn Davies <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

Hello Elwyn,

Sorry for being a pain. I have one more comment.

/Ludwig (now finally from the corporate account)

From: elwynd <[email-masked] <mailto:[email-masked]> > 
Sent: den 22 december 2019 19:27
To: Ludwig Seitz <[email-masked] <mailto:[email-masked]> >; Elwyn Davies <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06

Hi, Ludwig.

Having had another look at section 3.1 of draft-ietf-ace-cwt-proof-of-possession, technically the rules about which keys have to be present are not part of the syntax of the cnf claim.  The point can be covered by changing '"syntax of the 'cnf' claim"

to "syntax and semantics of the 'cnf' claim"

in each case.

[LS] Ok. Will do.

However, the second look threw up another point:  Figure 2 in s3.2 gives a Symetric key example  - I think this should use an Encrypted_COSE_Key (or Encrypted_COSE_Key0) as described in section 3.3 of draft-ietf-ace-cwt-proof-of-possession.

[LS] Figure 2 in 3.2 gives an example of a AS response to a client requesting an access token. As per the requirements from draft-ietf-ace-oauth-authz, this communication MUST be confidentiality protected, therefore it is unnecessary to additionally encrypt the COSE_Key. 

The provisions in 3.3 of draft-ietf-ace-cwt-proof-of-possession are for access tokens in CWT format, containing a symmetric key, that are not encrypted themselves (i.e. only MAC:ed or signed).

[JLS] I tend to agree with not doing the encryption in the example.  The encryption is not required as protection could be done elsewhere and having an example that people can read increases the usability of the example.

Jim

Otherwise I think we are done.

Eventually we will get to Christmas!  

[LS] I promise to leave it be over the holidays.