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 <bcampb...@pingidentity.com> 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig <ludwig.se...@combitech.se>
Cc: Ludwig Seitz <ludwig_se...@gmx.de>; Roman Danyliw <r...@cert.org>; 
oauth-ext-rev...@ietf.org; Daniel Migault <daniel.miga...@ericsson.com>; Jim 
Schaad <i...@augustcellars.com>; Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org; 
drafts-lastc...@iana.org
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 <ludwig.se...@combitech.se 
<mailto:ludwig.se...@combitech.se> > wrote:

[snip] 

 

From: Ace <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> > 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...   

 

[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.

 

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.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to