Hi all, My two cents:
* It would be good to officially revise the semantics of "ace_profile", per the alternative 1 from Göran (i.e., a single integer to select a single profile). In that case, a follow-up successful response MAY include "ace_profile" (although it would just redundantly confirm the accepted selection). At least for now, I would not consider further formats such as an array of integers for the AS to pick up from.
* As I see it, this point was not (clearly) specified in RFC 9200 (i.e., it is underspecified), so I believe that fixing it goes beyond an erratum to RFC 9200 and is more appropriate for an update to RFC 9200. That can be a short separate draft, or we can instead do that too as part of the draft at [0]. No strong opinion about which is best.
There is one more point, irrespective of how the above develops: after better checking RFC 9200, I notice that the IANA registrations have not taken into account the possible "null" use of "ace_profile" in the Access Token Request to the AS.
This can be fixed with an erratum (or two separate errata?) as below:* Section 5.8.5 - The entry for "ace_profile" in Table 5 should not say "integer" as Value Type, but instead "Null or integer". The entry for "ace_profile" in the IANA registry at [1] should be updated accordingly.
* Section 8.9 - "Parameter Usage Location" should not say "token response", but instead "token request, token response". The entry for "ace_profile" in the IANA registry at [2] should be updated accordingly.
Best, /Marco [0] https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/[1] https://www.iana.org/assignments/ace/ace.xhtml#oauth-parameters-cbor-mappings
[2] https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
On 2024-12-09 13:15, Göran Selander wrote:
Hi Christian, Inline. On 2024-12-09, 12:33, "Christian Amsüss" <christ...@amsuess.com> wrote: Hi Göran! On Mon, Dec 09, 2024 at 10:46:06AM +0000, Göran Selander wrote: > Good questions. As I recall, the mindset for this was that the AS > should have the necessary information about the capability of RS and > the intended use of the resources, to decide which profile to use. > This also simplified the protocol, where the only alternative given > was that the AS needed to be explicit about the decision if > ace_profile = null in the request. But perhaps this was too simple. That sounds like a "should" (but the grammar allows otherwise because there are cases when one would do otherwise)? GS:If ace_profile in request equals null/empty, then MUST ace_profile with non-null value in response. If no ace_profile in request then MAY ace_profile in response.> If we want to consider Client profile preferences in the ace_profile, > we need to handle potential contradiction with AS (incl. RS) > preferences, and the associated complication of the protocol - we may > run into some sort of negotiation. There's no "if" there. We *already* have to consider what happens if the client disagrees with the server, for example when the AS expects that C and RS would talk ACE-EDHOC-OSCORE profile, but the client didn't send and PoP a key for it. > As I understand, we can handle the current situation (although perhaps > not in a structured and extensible way). If this is something we want > to solve in a more structured way? If so, what is the desired > behaviour between C and AS? >> 1. C proposes one profile, AS accepts/rejects (with error incompatible_ace_profiles)> 2. C lists profiles in order of preference. AS selects the first in policy or else rejects (with error incompatible_ace_profiles)> 3. ? > > Compatibility with the semantics of the null value must also be ensured. I think 1 is what we practically have already: The AS may reject it (like in the case above). The only unclear point is whether C can be explicit in its expectation by sending a non-null value. The semantics of the null value are unharmed by that. There might be a case for 2, but I don't have it; I'd guess that sensible semantics are as you describe, with the addition that whenever a list is offered, the response would be explicit. In short, this sounds to me as if 9200 was ambiguous, the intention was to not allow profile values in requests, but there's no harm in allowing it in an erratum (given that it was not explicitly stated as forbidden).GS: I agree with the gist of the last part of the sentence but I don’t think that characterizes “ambiguous”, it is rather “unspecified” or “extensible” 😊.GS: So, it seems case 1 could be a useful update. That would also be applicable to draft-ietf-ace-group-oscore-profile. But I don’t see this as an erratum, seems more like a short draft to me.Göran _______________________________________________ Ace mailing list --ace@ietf.org To unsubscribe send an email toace-le...@ietf.org
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
