Hi Ludwig, Jim, Thanks for your input.
Ludwig: I agree with you, they do not belong in the token request. I would be fine with not registering them as OAuth parameters and only register them as Ace parameters, but if I understand correctly the only way to register Ace parameters right now is: 1. register them in the OAuth Parameter Registry 2. register the CBOR mapping in the OAuth Parameters CBOR Mappings Registry. Did I miss something? Is there a better registry where to put these? Otherwise I am ok with defining a new category, more on that below. > [JLS] Look at the OAuth registries - they have some "standardized" names for > these interactions as well as the RS-AS pair. Jim: yes, they have standardized names, but as far as I can see only those 4 (token request/response, authorization request/response) are allowed in this registry (see https://tools.ietf.org/html/rfc6749#section-11.2.1 ), and they seem to indicate C-resource owner and C-AS messages. I went and checked the registry [*], and there is actually one exception from Kantara UMA, they registered some parameters with the following locations: "client request", "token endpoint", " authorization server response". So now I am wondering what these locations mean, and how come they have managed to register parameters with locations outside of the template. I am fine with using "client request" and "resource server response" but these are not standardized names in OAuth. I think the best way forward is: agree within the working group on some names (such as those above, or better ones if you have proposals), then request the OAuth Parameters Registry expert review, which is necessary for IANA ok. [*] https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters On 31/08/2020, 15:42, "Seitz Ludwig" <ludwig.se...@combitech.se> wrote: 1.) I would not put these parameters in the "token request" category, they belong into a new category. Whether they should be registered in the OAuth parameters registry is doubtful to me, since I don't see them being used in a non-ACE OAuth context. Somewhere in the ACE registries? 2.) I would propose to put it on ACE page to be created for the framework by IANA. /Ludwig -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Francesca Palombini Sent: den 31 augusti 2020 14:53 To: Ace Wg <ace@ietf.org> Cc: ace-cha...@ietf.org Subject: [Ace] OSCORE Profile IANA questions Hi all, I have two quick questions concerning IANA actions to be done for the OSCORE profile: 1) The framework (-params) and the profile are currently conflicting on the registration of parameters, and we need to fix that. In the framework, parameters that are sent from Client to AS (such as req_cnf) are registered in the OAuth Parameters Registry as having "Parameter Usage Location: token request". The OSCORE profile registers parameters sent from Client to RS (such as nonce1) with "Parameter Usage Location: token request". The possible "Parameter Usage Location" are "token request" "token response" "authorization request" "authorization response" (see https://tools.ietf.org/html/rfc6749#section-11.2.1 ). It seems that "authorization request/response" are to the Resource Owner, and "token request/response" are to the Authorization Server. I think the framework is using the right names, but I am not sure what other location to put there, I think there is no name for Client-to-RS and RS-to-Client in the registry right now. 2) The OSCORE profile defines a new registry, the OSCORE Security Context Parameters registry. The question is where to put this registry? My proposal is to put it under https://www.iana.org/assignments/core-parameters/core-parameters.xhtml . Any objections? Thanks, Francesca _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
