Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

From: Ludwig Seitz <[email-masked]>
Date: Tue, 7 Jan 2020 20:45:55 +0100

On 2019-12-23 22:32, Brian Campbell wrote:
> The OAuth Token Introspection Response registry
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response>
> already has an entry for "cnf", which makes the first request in
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4
> rather problematic.
>

OAuth beats us on the finish line again :-(

I have updated the draft to remove the registration and refer to the
MTLS draft.

/Ludwig

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jan 2020 13:16:05 -0700

That certainly takes care of the registry conflict problem, thanks.

I'm a little confused, however, and uncertain if that changes the syntax in
a way that maybe wasn't intended?

-09 had:
  cnf
     OPTIONAL.  This field contains information about the proof-of-
     possession key that binds the client to the access token.  Values
     of this parameter follow the syntax of the "cnf" claim from
     section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession].  See
     Section 5 for additional discussion of the usage of this
     parameter.

while -10 has:
  Furthermore the AS can use the "cnf" parameter specified in section
  9.4 of [I-D.ietf-oauth-mtls] in an introspection response.  For CBOR-
  based interactions the AS MUST use the parameter mapping specified in
  Figure 5.

So in -09 the "cnf" Introspection Response Parameter was the following the
syntax of the "cnf" claim from PoP Key Semantics for CWTs
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax
of PoP Key Semantics for JWTs [RFC7800] transitively via
[I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key
semantics documents are conceptually the same or similar. But I don't know
that the syntax is the same? Figure 5
<https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6> is
pointed to for mapping between CBOR and JSON but it only has mappings for
the main top level parameters. Maybe I just don't get it or am missing
something...

On Tue, Jan 7, 2020 at 12:46 PM Ludwig Seitz <[email-masked]> wrote:

> > <
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response
> >

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Seitz Ludwig <[email-masked]>
Date: Sat, 11 Jan 2020 15:19:22 +0000

Hello Brian,

Thank you for the re-review! Comments inline.
I will be issuing a draft update soon-ish.

/Ludwig

From: Ace <[email-masked]> On Behalf Of Brian Campbell
Sent: den 10 januari 2020 21:16
To: Ludwig Seitz <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; [email-masked]; Daniel Migault <[email-masked]>; Jim Schaad <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

I'm a little confused, however, and uncertain if that changes the syntax in a way that maybe wasn't intended?

[LS] Indeed. Good catch. I amended that to say that it uses the “cnf” parameter for mtls, but for CBOR it should use the syntax of the “cnf” values from I-D.ietf-ace-cwt-proof-of-possession.

-09 had:
  cnf

while -10 has:

So in -09 the "cnf" Introspection Response Parameter was the following the syntax of the "cnf" claim from PoP Key Semantics for CWTs [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key semantics documents are conceptually the same or similar. But I don't know that the syntax is the same? Figure 5<https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6> is pointed to for mapping between CBOR and JSON but it only has mappings for the main top level parameters. Maybe I just don't get it or am missing something...

[LS] No you are not missing something, I just got sloppy trying to do a quickfix.

Background: The reason for defining both JSON and CBOR-based interactions is that you might have a powerful client communicating with a constrained RS. The client does vanilla OAuth interactions with the AS via the token endpoint, but is served a CWT and associated ACE parameters (cnf, ace-profile, …) for interaction with the RS.
The pop-key should decode to the same binary representation regardless of whether it came in a JSON or CBOR wrapper.

On Tue, Jan 7, 2020 at 12:46 PM Ludwig Seitz <[email-masked]<mailto:[email-masked]>> wrote:

/Ludwig

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Jan 2020 11:01:10 -0700

Thanks Ludwig,

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <[email-masked]>
wrote:

> [snip]
>
>
>
> *From:* Ace <[email-masked]> *On Behalf Of *Brian Campbell
>
>
> [snip]
>
>
>
> Background: The reason for defining both JSON and CBOR-based interactions
> is that you might have a powerful client communicating with a constrained
> RS. The client does vanilla OAuth interactions with the AS via the token
> endpoint, but is served a CWT and associated ACE parameters (cnf,
> ace-profile, …) for interaction with the RS.
>
> The pop-key should decode to the same binary representation regardless of
> whether it came in a JSON or CBOR wrapper.
>

Okay, so noting that there is cnf content that doesn't decode to a key, I
suppose I'll just take it on faith that all the relevant or expected usages
involve a key that can be represented in both CBOR and JSON.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 13 Jan 2020 10:37:49 -0800

Brian,

If it does not work then I should know by the end of next week.  I am trying to merge my JWT and CWT token issuing code in my ACE OAuth server right now.

Jim

From: Brian Campbell <[email-masked]> 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig <[email-masked]>
Cc: Ludwig Seitz <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]; Daniel Migault <[email-masked]>; Jim Schaad <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

Thanks Ludwig,

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <[email-masked] <mailto:[email-masked]> > wrote:

[snip] 

From: Ace <[email-masked] <mailto:[email-masked]> > On Behalf Of Brian Campbell

[snip]

So in -09 the "cnf" Introspection Response Parameter was the following the syntax of the "cnf" claim from PoP Key Semantics for CWTs [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key semantics documents are conceptually the same or similar. But I don't know that the syntax is the same? Figure 5 <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6>  is pointed to for mapping between CBOR and JSON but it only has mappings for the main top level parameters. Maybe I just don't get it or am missing something...   

Okay, so noting that there is cnf content that doesn't decode to a key, I suppose I'll just take it on faith that all the relevant or expected usages involve a key that can be represented in both CBOR and JSON. 

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Jim Schaad <[email-masked]>
Date: Sun, 19 Jan 2020 15:35:10 -0800

I have managed to merge most of my code that deals with the confirmation claim and I have ended up with a single problem when dealing with confirmations.  If this is going to get fixed, it needs to get fixed in draft-ietf-ace-cwt-proof-of-possession prior to this document finishing processing the EDIT process in the RFC editor.

All of the items that can appear in a confirmation claim are unique except for the ‘kid’ claim method.  This field is defined as being a text field for JWT (RFC 7800), but it is defined as being a binary field for CWT.  It is a text field when defined in RFC 7800.  I do not anticipate any issues for the definition of a thumbprint as COSE is using a very different format for the definition of thumbprints which will led to a different naming convention.

Jim

Thanks Ludwig,

[snip] 

[snip]

---

From: Jim Schaad <[email-masked]>
Date: Mon, 20 Jan 2020 13:12:08 -0800

I started doing testing of my code and I have started to run into some massive problems with the confirmation claim.    The COSE version of the POP key registrations cause a problem because of the way the registration template in the document is written.  It currently says:

JWT Confirmation Method Name:

Claim Name of the equivalent JWT confirmation method value, as

registered in [IANA.JWT.Claims <https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#ref-IANA.JWT.Claims> ].  CWT claims should normally have

a corresponding JWT claim.  If a corresponding JWT claim would not

make sense, the Designated Experts can choose to accept

registrations for which the JWT Claim Name is listed as "N/A".

The issue here is the word “equivalent”.  There are two possible interpretations of this:  That this is a similar item in terms of how things are used, but there is no way to encode this item into a JWT.  Or, that this is how one should encode this item in a JWT.  The first interpretation implies that even though one would like to pass a COSE_Key confirmation in a JWT there is no way to do this.  (Yes, one can potentially convert the COSE Key into a JOSE Key but that is not always going to succeed as some keys in one system may not be representable in the other system.) The second interpretation says that you just encode the COSE_Key as JSON and put it into the map with the ”jwk” key and you are happy.  Which of course will not work.

I had misled myself in the message below as I had missed reading the JWT Confirmation Method Name field in the registration templates.   If you look at the text below, it is hard to know if “COSE_Key” is to be used in a JSON structure (which I had originally assumed) or if “jwk” is supposed to be used in a JSON structure.

   o  Confirmation Method Name: "COSE_Key"
   o  Confirmation Method Description: COSE_Key Representing Public Key
   o  JWT Confirmation Method Name: "jwk"
   o  Confirmation Key: 1
   o  Confirmation Value Type(s): COSE_Key structure
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 <https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#section-3.2>  of [[ this document ]]

At a minimum we should probably clarify the language on this.  And I need to look at the COSE documents and decode if there needs to be some text on encoding in a JSON environment or not.

Jim

From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Sunday, January 19, 2020 3:35 PM
To: 'Brian Campbell' <[email-masked]>; 'Seitz Ludwig' <[email-masked]>
Cc: 'Roman Danyliw' <[email-masked]>; [email-masked]; 'Daniel Migault' <[email-masked]>; [email-masked]; 'Ludwig Seitz' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>; [email-masked]
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

Jim

From: Brian Campbell <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig <[email-masked] <mailto:[email-masked]> >
Cc: Ludwig Seitz <[email-masked] <mailto:[email-masked]> >; Roman Danyliw <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Daniel Migault <[email-masked] <mailto:[email-masked]> >; Jim Schaad <[email-masked] <mailto:[email-masked]> >; Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

Thanks Ludwig,

[snip] 

[snip]

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jan 2020 17:39:49 -0800

I want to double-check that I'm understanding you correctly.

The idea is that there's ambiguity about how a CWT 'cnf' claim would get
represented as "equivalent" JWT, and that it may not even be possible for
some 'cnf' values?  I'm not entirely sure what the path forward even looks
like, and thus am inclined to believe that I should request an IESG hold on
the publication of draft-ietf-ace-cwt-proof-of-possession.

Is that right?

Thanks,

Ben