AccessTokenRequest does not support profile selection

[chrysn]

Describe the bug

In AccessTokenRequest, the ace_profile parameter is only ever absent or present-but-null, but no concrete selection of a profile is possible.

To Reproduce

Signature of the field and corresponding functions is pub ace_profile: Option<()>

Expected behavior

The signature should be something more like pub ace_profile: Option<Option<dcaf::AceProfile>>, with None signifying that nothing is expresed, and Some(None) signifying the null value.

Additional context

RFC9200 is not too explicit here -- it talks a lot about the null value being allowed in requests (section 5.8.1. and 5.8.4.3.), but neither allows nor forbids regular values.

When a server supports multiple profiles and a client is authorized to use them, both the client telling the server what to select (eg. because of circumstances like limited network availability) and for the server to select (client sends null, server responds with what it selected, which is a sensible default).

If you disagree with my interpretation of 9200, I'm happy to file an erratum about this allowing different interpretations; not filing one immediately because this may just be an oversight.

[falko17]

Thank you for the detailed description. My original interpretation of RFC9200 was actually that clients can only either leave the ace_profile parameter out, or leave it empty (hence the type of ace_profile in dcaf-rs).

Reading over it again, I definitely agree that the RFC is vague here—by not disallowing any regular values, it can also be interpreted to mean that the parameter doesn't necessarily have to be empty. If it is meant to also allow regular values, though, I find it slightly confusing that this seemingly isn't mentioned anywhere else in the specification. There are several places about "the server selecting the profile"¹, but I can't find anything about the client selecting the profile.

There is also this paragraph from section 5.8.2, which makes it sound to me like the AS decides on its own which profile to use, with the client not really having a direct say:

Note that the AS decides which token type and profile to use when issuing a successful response. It is assumed that the AS has prior knowledge of the capabilities of the client and the RS (see Appendix D). [...] If the client has requested a specific proof-of-possession key using the req_cnf parameter from [RFC9201], this may also influence which profile the AS selects, as it needs to support the use of the key type requested by the client.

If the client had the ability to influence the AS's choice of profile through ace_profile, I would've expected that to be mentioned here. All in all, I'm unsure what the intended meaning actually is (although I'm leaning towards the "either empty or absent" interpretation), so filling an erratum might make sense here.

Footnotes

1. For example, "the AS is expected to manage the matching of compatible profile choices between a client and an RS. The AS informs the client of the selected profile using the ace_profile parameter in the token response." (in section 5) ↩

[chrysn]

Relayed to the ACE mailing list for clarification before going all erratum; archived-at https://mailarchive.ietf.org/arch/msg/ace/eC0mQN8Jy1DoHH9lyib5zxC5MJM, I'll report back here once that is concluded.