Hello Brian,
Thank you for the re-review! Comments inline.
I will be issuing a draft update soon-ish.
/Ludwig
From: Ace <ace-boun...@ietf.org> On Behalf Of Brian Campbell
Sent: den 10 januari 2020 21:16
To: Ludwig Seitz <ludwig_se...@gmx.de>
Cc: 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
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?
[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
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...
[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
<ludwig_se...@gmx.de<mailto:ludwig_se...@gmx.de>> wrote:
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
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
