+1 --Cigdem
On Tue, 10 Dec 2024 at 08:30, Marco Tiloca <marco.tiloca= 40ri...@dmarc.ietf.org> wrote: > 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> > <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 to ace-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 > > _______________________________________________ > Ace mailing list -- ace@ietf.org > To unsubscribe send an email to ace-le...@ietf.org >
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
