Subject: [Ace] Progressing draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Tue, 26 Oct 2021 11:57:03 +0000

Hello ACE (Cc to OAuth designated expert Justin),

The progress of draft-ietf-ace-oauth-authz is currently blocked due to an issue that has come to light in the IANA review process, and I'd like to solicit the feedback of the WG to determine how to go forward.

The issue is related to parameters used by the AS when responding to an Introspection query (see https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-5.9.2). Our approach so far has been to map all OAuth parameters to ACE and map all parameters created for the ACE interaction back to OAuth. The issue is that some of the ACE parameters (cnonce and cti, see Figure 16) have the datatype "byte string". In OAuth the Introspection parameters are formatted as JSON payload, which precludes the use of raw byte strings, a fact we overlooked when we tried to register the new parameters in the OAuth registry ( see https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response).

My proposed fix for this would be to amend the descriptions of these two parameters in 5.9.2, specifying that their JSON representation is a text string containing the Base64url encoding of the original byte string payload.

Does the working group or the OAuth designated expert have any objections (or suggestions) to this approach?

Regards,

Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
[email-masked] . combitech.com This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above of any such misdirection Please consider the environment before printing this e-mail!

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 26 Oct 2021 14:05:33 +0200

HI,

"My proposed fix for this would be to amend the descriptions of these 
two parameters in 5.9.2, specifying that their JSON representation is a 
text string containing the Base64url encoding of the original byte 
string payload."

exactly the same fix we did for json and cbor voucher-request payloads 
in brski.

Peter
Ludwig Seitz schreef op 2021-10-26 13:57:

> The progress of draft-ietf-ace-oauth-authz is currently blocked due to 
> an issue that has come to light in the IANA review process, and I'd 
> like to solicit the feedback of the WG to determine how to go forward.
> 
> The issue is related to parameters used by the AS when responding to an 
> Introspection query (see 
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-5.9.2). 
> Our approach so far has been to map all OAuth parameters to ACE and map 
> all parameters created for the ACE interaction back to OAuth. The issue 
> is that some of the ACE parameters (cnonce and cti, see Figure 16) have 
> the datatype "byte string". In OAuth the Introspection parameters are 
> formatted as JSON payload, which precludes the use of raw byte strings, 
> a fact we overlooked when we tried to register the new parameters in 
> the OAuth registry ( see 
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response).
> 
> My proposed fix for this would be to amend the descriptions of these 
> two parameters in 5.9.2, specifying that their JSON representation is a 
> text string containing the Base64url encoding of the original byte 
> string payload.
> 
> Does the working group or the OAuth designated expert have any 
> objections (or suggestions) to this approach?
> 
> Regards,
> 
> Ludwig
> 
> --
> Ludwig Seitz
> [email-masked] . combitech.com This e-mail is private and 
> confidential between the sender and the addressee. In the event of 
> misdirection, the recipient is prohibited from using, copying or 
> disseminating it or any information in it. Please notify the above of 
> any such misdirection Please consider the environment before printing 
> this e-mail!
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Justin Richer <[email-masked]>
Date: Tue, 26 Oct 2021 10:06:39 -0400

That solution is fine with me. From RFC7662’s perspective, JSON is the canonical form, and any other representation should be able to be translated from that. While not mentioned in 7662, I see no problem with other representations having special optimizations for any given field, and so this approach makes sense.

Please be very specific with the string definition though: Base64 URLSafe encoding with no padding.

Thanks,
 — Justin

> On Oct 26, 2021, at 7:57 AM, Ludwig Seitz <[email-masked]> wrote:
>