Subject: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jul 2019 10:56:06 -0500

We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks
for readability".

Section 2

   Presenter
      Party that proves possession of a private key (for asymmetric key
      cryptography) or secret key (for symmetric key cryptography) to a
      recipient.

nit: it might be worth either capitalizing Recipient to point to the
following item more clearly, or specifying "recipient of a CWT" for
parallelism with Recipient.
(If we do the former we should capitalize Presenter in the following
definition.  But since we don't use the capitalized terms throughout the
text, it wouldn't be my own preference.)

Section 3.2

This example key expired in 2013.  While the example will "always" be
expired for an archival document, it might be worth making it more
timely with respect to the publication date.  (This holds for basically
all time values in the document's examples.)

Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.

[I did not check that the example x and y coordinates are in fact points
on P256.]

   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.

It's hard for me to escape the conclusion that this paragraph needs to
be a dedicated section with a bit more discussion about how exactly this
usage is performed and encoded.

Section 3.3

Is the /HMAC256/ the conventional diagnostic notation for alg value 5
(noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?

   The following example CWT Claims Set of a CWT (using CBOR diagnostic
   notation, with linebreaks for readability) illustrates the use of an
   encrypted symmetric key as the "Encrypted_COSE_Key" member value:

  {
   /iss/ 1 : "coaps://server.example.com",
   /sub/ 2 : "24400320",
   /aud/ 3: "s6BhdRkqt3",
   /exp/ 4 : 1311281970,
   /iat/ 5 : 1311280970,
   /cnf/ 8 : {
   /COSE_Encrypt0/ 2 : [

Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?

[I did not validate the COSE_Encrypt0 output]

Section 3.4

     {
      /iss/ 1 : "coaps://server.example.com",
      /aud/ 3 : "coaps://client.example.org",

Is it in any way confusing to use client.example.org as opposed to, say,
resource.example.org as the audience?

      /exp/ 4 : 1361398824,
      /cnf/ 8 : {
        /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'

/kid/ in the 'cnf' map has key 3, not 2.

   Note that the use of a Key ID to identify a proof-of-possesion key
   needs to be carefully circumscribed, as described below and in
   Section 6.  Where the Key ID is not a cryptographic value derived
   from the key or where all of the parties involved are not validating
   the cryptographic derivation, it is possible to get into situations
   where the same Key ID is being used for multiple keys.  The

I don't think this quite covers the needed properties, since we also
need some assurance that all parties are interpreting the kid value in
the same way. It may be possible to construct such a scenario via an
attacker replaying a stolen token or even just inadvertent confusion by
some party (quite plausible when we consider scenarios that involve the
same key being described by different 'kid' values in messages with
different recipients).  In particular, if the situation arises where an
attacker is able to choose the 'kid' value that will be used, they could
deliberately cause a collision with a legitimate value used by some
other party.

   In the world of constrained Internet of Things (IoT) devices, there
   is frequently a restriction on the size of Key IDs, either because of
   table constraints or a desire to keep message sizes small.  These
   restrictions are going to protocol dependent.  For example, DTLS can

nit: "going to be" or maybe even just "are protocol dependent".

   use a Key ID of any size.  However, if the key is being used with
   COSE encrypted message, then the length of the key needs to be
   minimized and may have a limit as small as one byte.

nit: is this "length of the key" or "length of the key ID"?

   Note that the value of a Key ID is not always the same for different
   parties.  When sending a COSE encrypted message with a shared key,
   the Key ID may be different on both sides of the conversation, with
   the appropriate one being included in the message based on the
   recipient of the message.

While this recipient-dependence is probably unavoidable (as the
requisite namespacing would use more space on the wire than is
reasonable for many applications), it does merit some security
considerations text, noting that such messages are context-dependant and
could be misinterpreted if presented in a different context.
Audience restrictions, as mentioned in Section 4, provide substantial
protection in this regard, but are not necessarily a complete solution.

   o  A recipient can decide not to use a CWT based on a created Key ID
      if it does not fit the recipient's requirements.

I'm not sure I understand the semantics being described here.  Are we
saying that the issuer might give a presenter a CWT, and by the time the
presenter presents the CWT to the recipient, the recipient says "this is
no good" and denies the transaction in question, forcing the presenter
to go back to the issuer and try again?  (How do we know that the issuer
would make any different choices the second time around?)

   o  If an issuer is going to use the Key ID confirmation method and is
      not going to guarantee that serial number uniqueness is going to
      be preserved, the recipient needs to have that information
      configured into it so that appropriate actions can be taken.

nit: this is the only place in the document that talks about "serial
number"s.
Do we say what the "appropriate actions" are somewhere else in the
document?

Section 3.5

   Note that another means of proving possession of the key when it is a
   symmetric key is to encrypt the key to the recipient.  The means of
   obtaining a key for the recipient is likewise protocol specific.

While true, there are some subtleties here, namely that the recipient
needs some way of knowing that it is the presenter (as opposed to some
other party) that has actually performed that encryption.  In Kerberos
we perform this key confirmation by using the encrypted (session) key
for subsequent protocol exchanges, and if the presenter fails to process
those exchanges then it is clear the presenter does not actually possess
the key.  This document does not seem to describe the need for such
subsequent confirmation (or, alternately, the consequences of failing to
do so.)

Section 4

   A recipient might not understand the "cnf" claim.  Applications that
   require the proof-of-possession keys communicated with it to be
   understood and processed MUST ensure that the parts of this
   specification that they use are implemented.

nit(?): I'm not sure I'm parsing this sentence correctly: is
"communicated with it" referring to "CWTs that include the 'cnf' claim"?

                To avoid replay attacks when the proof-of-possession
   tokens are sent to presenters, a security protocol, which uses
   mechansims such as nonces or timestamps, has to be utilized.  [...]

I suspect the RFC Editor will want to reword this sentence to avoid the
excessive parentheticals and awkward passive-voice construction.  I'll
be bold and suggest a more dramatic rewording to preempt that: "Proof of
possession only provides the intended security gains when the proof is
known to be current and not subject to replay attacks; security
protocols using mechanisms such as nonces and timestamps can be used to
avoid this risk of replay when sending proof-of-possession tokens to
[presenters or recipients]".  Note that I am not sure if the original
was intended to refer to the transfer of PoP tokens to presenters (as
written) or recipients (where risk of replay is more traditionally
concerned).

   from changing any elements conveyed within the CWT payload.  Special
   care has to be applied when carrying symmetric keys inside the CWT
   since those not only require integrity protection but also
   confidentiality protection.

Do we want to reiterate the common mechanisms for providing
confidentiality protection here, or just leave the existing text earlier
in the document to cover it?

Section 5

This sort of correlation can occur even for subsequent connections
between the same two parties if observed by a passive observer (e.g., in
the case of a mobile client that changes location).  I forget if we have
strong enough guarantees on the use of transport-level encryption that
would prevent such CWTs from being observed in this fashion.

Section 6

   ensure correct processing.  The recipient needs to be able to use
   credentials to verify the authenticity, integrity, and potentially
   the confidentiality of the CWT and its content.  This requires the

Just from a rhetorical point of view, can you help me understand how
credentials would be used to verify the confidentiality of a CWT?  It
seems like this depends on either (or both of) how the CWT is
transmitted or how it is prepared, and I am not sure how the recipient's
credentials come into play.

   recipient to know information about the issuer.  Likewise, there
   needs to be agreement between the issuer and the recipient about the
   claims being used (which is also true of CWTs in general).

We briefly discuss the presenter (in the guise of the subject) in the
next paragraph when we talk about key IDs, but are there any other cases
where there needs to be coordination with the presenter?  Would
distributing a symmetric PoP key be considered to fall under this
mantle?

   When an issuer creates a CWT containing a Key ID claim, it needs to
   make sure that it does not issue another CWT containing the same Key
   ID with a different content, or for a different subject, within the
   lifetime of the CWTs, unless intentionally desired.  Failure to do so
   may allow one party to impersonate another party, with the potential
   to gain additional privileges.  Likewise, if PoP keys are used for

nit: "same Key ID with a different content" doesn't seem quite right, as
the "content" of a Key ID is surely the key-ID value itself.  Perhaps
"referring to" would be more appropriate.
I think we should probably give the reader some indication of what
semantics might be attributed to the "intentionally desired" case.  It
doesn't necessarily need to be a specific example, but we could say what
the relevant properties/attributes that might lead to such a situation
would be.

   multiple different kinds of CWTs in an application and the PoP keys
   are identified by Key IDs, care must be taken to keep the keys for
   the different kinds of CWTs segregated so that an attacker cannot
   cause the wrong PoP key to be used by using a valid Key ID for the
   wrong kind of CWT.

Audience restrictions can come into play here, too, right?  In that a
restricted audience of all the CWTs in turn limits the scope of
administration in which this care/segregation needs to be enforced.

Section 7

   Criteria that should be applied by the Designated Experts include
   determining whether the proposed registration duplicates existing
   functionality, determining whether it is likely to be of general
   applicability or whether it is useful only for a single application,
   and evaluating the security properties of the item being registered
   and whether the registration makes sense.

I know we've been using (variations of) this text for a while, but it
seems to me that it could be more clear than it currently is -- is
duplication of functionality grounds for denial of registration?  What
about general vs. specific applicability?  The latter seems more clearly
applicable for determining which range from which to allocate, since
that has impact on the encoding size.  Can the experts insist on updates
to the security considerations text of a specification prior to granting
approval, or are they limited to denying registration of values with
poor security properties or insufficient documentation thereof?

Section 7.2.1

   Change Controller:
      For Standards Track RFCs, list the "IESG".  For others, give the
      name of the responsible party.  Other details (e.g., postal
      address, email address, home page URI) may also be included.

In light of the GDPR and similar regulations (and, as is done in RFC 8602), we
may not want to keep all of these, especially postal address, given the lack of
a clear need.

   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of

Is the reference required to be publicly accessible?  If not, is it
required that a copy be made available to the experts and IANA?

Section 7.2.2

   o  Confirmation Method Name: "Encrypted_COSE_Key"
   o  Confirmation Method Description: Encrypted COSE_Key
   o  JWT Confirmation Method Name: "jwe"
   o  Confirmation Key: 2
   o  Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
      structure (with an optional corresponding COSE_Encrypt or
      COSE_Encrypt0 tag)

Do we want to say something about how, in the case when the tag is
omitted, the application protocol specification needs to indicate how to
determine which one is in use?

Section 8.2

I think [JWT] needs to be normative, as we have a SHOULD-level
requirement for the audience restriction procedures it specifies.

I just want to check that it's intentional/desired to mix descriptive
reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for
the referenced RFCs.

Acknowledgements, Authors

The datatracker is currently accepting XML v3 format drafts, and the RFC
Editor's target cutover date for the end of August is quite soon, so
feel free to consider using an XML v3 submission with UTF-8
representations of names not well represented by the ASCII subset.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Jul 2019 10:10:12 -0700

Comments inline.

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Tuesday, July 30, 2019 8:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06

We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks for
readability".

[JLS] I don't believe that this disclaimer needs to be present.  Unlike the
JSON document where what is being presented is in fact JSON, what is being
presented here is simply a more user friendly readable version of the binary
data.  (A different question would be if the hex should be presented but
that is not what the ACE group is doing in general.)

Section 2

   Presenter

Section 3.2

This example key expired in 2013.  While the example will "always" be
expired for an archival document, it might be worth making it more timely
with respect to the publication date.  (This holds for basically all time
values in the document's examples.)

[I did not check that the example x and y coordinates are in fact points on
P256.]

It's hard for me to escape the conclusion that this paragraph needs to be a
dedicated section with a bit more discussion about how exactly this usage is
performed and encoded.

Section 3.3

[JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is
descriptive.  I believe that this is completely consistent in RFC 8152.

  {

Section 3.4

     {

      /exp/ 4 : 1361398824,
      /cnf/ 8 : {

I don't think this quite covers the needed properties, since we also need
some assurance that all parties are interpreting the kid value in the same
way. It may be possible to construct such a scenario via an attacker
replaying a stolen token or even just inadvertent confusion by some party
(quite plausible when we consider scenarios that involve the same key being
described by different 'kid' values in messages with different recipients).
In particular, if the situation arises where an attacker is able to choose
the 'kid' value that will be used, they could deliberately cause a collision
with a legitimate value used by some other party.

[JLS] I don't agree with that.   It should be assumed by all implementations
that there will be collisions between kid values.  Except in very specific
cases such as all of the kids being assigned by a group keying server, there
is no way for the assumption of a single kid value being assigned once on a
recipient basis will ever be a true statement.  

While this recipient-dependence is probably unavoidable (as the requisite
namespacing would use more space on the wire than is reasonable for many
applications), it does merit some security considerations text, noting that
such messages are context-dependant and could be misinterpreted if presented
in a different context.
Audience restrictions, as mentioned in Section 4, provide substantial
protection in this regard, but are not necessarily a complete solution.

[JLS] Again I don't understand this, but I think that your concern goes away
if you do not assume that kid values are going to be unique for an entity.

I'm not sure I understand the semantics being described here.  Are we saying
that the issuer might give a presenter a CWT, and by the time the presenter
presents the CWT to the recipient, the recipient says "this is no good" and
denies the transaction in question, forcing the presenter to go back to the
issuer and try again?  (How do we know that the issuer would make any
different choices the second time around?)

nit: this is the only place in the document that talks about "serial
number"s.
Do we say what the "appropriate actions" are somewhere else in the document?

Section 3.5

While true, there are some subtleties here, namely that the recipient needs
some way of knowing that it is the presenter (as opposed to some other
party) that has actually performed that encryption.  In Kerberos we perform
this key confirmation by using the encrypted (session) key for subsequent
protocol exchanges, and if the presenter fails to process those exchanges
then it is clear the presenter does not actually possess the key.  This
document does not seem to describe the need for such subsequent confirmation
(or, alternately, the consequences of failing to do so.)

Section 4

nit(?): I'm not sure I'm parsing this sentence correctly: is "communicated
with it" referring to "CWTs that include the 'cnf' claim"?

I suspect the RFC Editor will want to reword this sentence to avoid the
excessive parentheticals and awkward passive-voice construction.  I'll be
bold and suggest a more dramatic rewording to preempt that: "Proof of
possession only provides the intended security gains when the proof is known
to be current and not subject to replay attacks; security protocols using
mechanisms such as nonces and timestamps can be used to avoid this risk of
replay when sending proof-of-possession tokens to [presenters or
recipients]".  Note that I am not sure if the original was intended to refer
to the transfer of PoP tokens to presenters (as
written) or recipients (where risk of replay is more traditionally
concerned).

Do we want to reiterate the common mechanisms for providing confidentiality
protection here, or just leave the existing text earlier in the document to
cover it?

Section 5

This sort of correlation can occur even for subsequent connections between
the same two parties if observed by a passive observer (e.g., in the case of
a mobile client that changes location).  I forget if we have strong enough
guarantees on the use of transport-level encryption that would prevent such
CWTs from being observed in this fashion.

[JLS] No we don't.  Most of the time we are sending CWTs in the clear and
not over a transport-level encrypted channel.

Section 6

Just from a rhetorical point of view, can you help me understand how
credentials would be used to verify the confidentiality of a CWT?  It seems
like this depends on either (or both of) how the CWT is transmitted or how
it is prepared, and I am not sure how the recipient's credentials come into
play.

We briefly discuss the presenter (in the guise of the subject) in the next
paragraph when we talk about key IDs, but are there any other cases where
there needs to be coordination with the presenter?  Would distributing a
symmetric PoP key be considered to fall under this mantle?

nit: "same Key ID with a different content" doesn't seem quite right, as the
"content" of a Key ID is surely the key-ID value itself.  Perhaps "referring
to" would be more appropriate.
I think we should probably give the reader some indication of what semantics
might be attributed to the "intentionally desired" case.  It doesn't
necessarily need to be a specific example, but we could say what the
relevant properties/attributes that might lead to such a situation would be.

Section 7

I know we've been using (variations of) this text for a while, but it seems
to me that it could be more clear than it currently is -- is duplication of
functionality grounds for denial of registration?  What about general vs.
specific applicability?  The latter seems more clearly applicable for
determining which range from which to allocate, since that has impact on the
encoding size.  Can the experts insist on updates to the security
considerations text of a specification prior to granting approval, or are
they limited to denying registration of values with poor security properties
or insufficient documentation thereof?

Section 7.2.1

   Change Controller:

In light of the GDPR and similar regulations (and, as is done in RFC 8602),
we may not want to keep all of these, especially postal address, given the
lack of a clear need.

Is the reference required to be publicly accessible?  If not, is it required
that a copy be made available to the experts and IANA?

[JLS] It is not clear to me that this is an Designated Expert registry.  It
is only referred to once in the JWT Confirmation Method Name and that could
refer to the JWT registry and not this one.

Section 7.2.2

Do we want to say something about how, in the case when the tag is omitted,
the application protocol specification needs to indicate how to determine
which one is in use?

[JLS] This is easy as the number of elements in the array is different
between the two.

Section 8.2

I think [JWT] needs to be normative, as we have a SHOULD-level requirement
for the audience restriction procedures it specifies.

[JLS] Should this be indirect through the CWT spec rather than via the JWT
spec?

I just want to check that it's intentional/desired to mix descriptive
reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for the
referenced RFCs.

[JLS] I have no problem with this.  I find descriptive reference tags to be
easier to identify than RFC number tags for which I only know  couple of
them.

The datatracker is currently accepting XML v3 format drafts, and the RFC
Editor's target cutover date for the end of August is quite soon, so feel
free to consider using an XML v3 submission with UTF-8 representations of
names not well represented by the ASCII subset.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jul 2019 21:31:17 +0200

On Jul 30, 2019, at 19:10, Jim Schaad <[email-masked]> wrote:
> data.  

Right.  But it is still useful for the reader to be able to look up how that notation works.

CBOR diagnostic notation was originally defined in Section 6 of RFC 7049, precisely for the purpose of discussing CBOR data items in a human-readable way.
Many current documents make use of some extensions of the original diagnostic notation, such as the use of whitespace in hex strings.  These extensions are documented in Appendix G of RFC 8610, Extended Diagnostic Notation (EDN).  This is what always should be referenced, and then no disclaimer is needed.

Grüße, Carsten

PS.:

> (A different question would be if the hex should be presented but

I don’t think that showing a hex representation of the encoded bytes is needed either; CBOR should be well-known enough to readers of this document via CWT already.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jul 2019 17:03:16 -0500

Noting that there are several points that Jim left to the authors to reply
to, also inline...

> that is not what the ACE group is doing in general.)

Taking it out is fine by me; I just want us to be internally consistent :)

> descriptive.  I believe that this is completely consistent in RFC 8152.

Er, I'm not sure what you're saying is best to use in the diagnostic
notation.

> recipient basis will ever be a true statement.  

Thanks; that's a good point, and this jogs loose some of the previous
discussions we had on the list about key IDs.  (Looking back at the quoted
text from the document, I wonder if all readers will understand that
"cryptographic value derived from the key" needs to include enough bits of
cryptographic output to make the chance of brute-force/random collision
acceptably small.)
It does still seem potentially useful to have agreement among parties as to
whether key IDs are arbitrary identifiers or cryptographically derived,
though my above discussion about scenarios and consequences is flawed as
you note.

> if you do not assume that kid values are going to be unique for an entity.

I think you are right about the concern going away.
Should we add some text to make it more explicit that all recipients should
expect key-ID collisions to occur and be prepared to do the necessary
processing/validation to resolve collisions?

> not over a transport-level encrypted channel.

I don't propose that we add or suggest remediation measures, but do think
we should note the risk.

> refer to the JWT registry and not this one.

Section 7 (toplevel) says that all new registries established by this
document use Specification Required [RFC8126], which includes review by an
expert or experts.

> [JLS] This is easy as the number of elements in the array is different

Okay, so you think it's obvious to anyone who goes off and tries to
implement it, so we don't need to say anything?

> [JLS] Should this be indirect through the CWT spec rather than via the JWT

Perhaps.  (The text in question in this doc is in Section 4, "Applications
utilizing proof of possession SHOULD also utilize audience restriction, as
described in Section 4.1.3 of [JWT], as it provides additional
protections.")  I guess JWT itself doesn't even use the phrase "audience
restrictions", so perhaps just changing to the CWT ref is enough, here.

> easier to identify than RFC number tags for which I only know  couple of

Sure.  I don't need to impose my personal preference on anyone, here; it
would be up to the RFC Editor to enforce a consistent style, if anyone
should.

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Jul 2019 15:49:43 -0700

I have deleted things I am not replying to.

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Tuesday, July 30, 2019 3:03 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06

[JLS] I would use the algorithm name if it was up to me.  That is what I did
in the COSE documents.

> Is it in any way confusing to use client.example.org as opposed to, 
> say, resource.example.org as the audience?
> 
>       /exp/ 4 : 1361398824,
>       /cnf/ 8 : {
> attacker replaying a stolen token or even just inadvertent confusion 
> by some party (quite plausible when we consider scenarios that involve 
> the same key being described by different 'kid' values in messages with
different recipients).
> In particular, if the situation arises where an attacker is able to 
> choose the 'kid' value that will be used, they could deliberately 
> cause a collision with a legitimate value used by some other party.
> 
> that there will be collisions between kid values.  Except in very 
> specific cases such as all of the kids being assigned by a group 
> keying server, there is no way for the assumption of a single kid 
> value being assigned once on a recipient basis will ever be a true
statement.

Thanks; that's a good point, and this jogs loose some of the previous
discussions we had on the list about key IDs.  (Looking back at the quoted
text from the document, I wonder if all readers will understand that
"cryptographic value derived from the key" needs to include enough bits of
cryptographic output to make the chance of brute-force/random collision
acceptably small.) It does still seem potentially useful to have agreement
among parties as to whether key IDs are arbitrary identifiers or
cryptographically derived, though my above discussion about scenarios and
consequences is flawed as you note.

[JLS] Yes I agree that it could do better about talking about lengths for
the purpose of non-collision.  I don't think that I care much about the
issue of brute-forcing as even if there is a faked kid, the shared secret
would still need to be determined which is more difficult.  And as below, I
don't think this is ever going to be a very big issue for the IoT world as
long enough kid values collides with as small as possible messages.

> between the same two parties if observed by a passive observer (e.g., 
> in the case of a mobile client that changes location).  I forget if we 
> have strong enough guarantees on the use of transport-level encryption 
> that would prevent such CWTs from being observed in this fashion.
> 
> [JLS] No we don't.  Most of the time we are sending CWTs in the clear 
> and not over a transport-level encrypted channel.

I don't propose that we add or suggest remediation measures, but do think we
should note the risk.

[JLS] reasonable (I guess)

> In light of the GDPR and similar regulations (and, as is done in RFC 
> 8602), we may not want to keep all of these, especially postal 
> address, given the lack of a clear need.
> 
> [JLS] It is not clear to me that this is an Designated Expert 
> registry.  It is only referred to once in the JWT Confirmation Method 
> Name and that could refer to the JWT registry and not this one.

[JLS] All one of them.  I think this can be pulled down close to the actual
registry declaration.

> omitted, the application protocol specification needs to indicate how 
> to determine which one is in use?
> 

[JLS] Yes I think so

> [JLS] Should this be indirect through the CWT spec rather than via the 
> JWT spec?

[JLS] Yeah, I looked at both and it seemed to me that the text was
essentially the same in both documents.

Jim

***

-Ben