Hello Daniel, I should clarify: I did not mean it was not compliant - it was more asking whether anybody objects to registering ace+json when the framework talks about a different method. Kind regards, --Cigdem
On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault <daniel.miga...@ericsson.com> wrote: > Hi, > > I am certainly missing something, but it is unclear to me why > "application/ace+json" does not comply to "application/x-www-form-urlencoded". > In other words, what would the update of the mqtt draft consist of to be > aligned with the framework. I also have the impression that the use of > "application/x-www-form-urlencoded" is a MAY and that the framework does > not specify MUST. In general I am tempted to think it is better to be > aligned with but It would probably need to understand better the issue and > I am encouraging the WG to state rapidly their thoughts so we can move the > draft forward. > > Regarding the second point, yes, the draft that introduces ace+json should > register it. > > Yours, > Daniel > ------------------------------ > *From:* Ace <ace-boun...@ietf.org> on behalf of Cigdem Sengul < > cigdem.sen...@gmail.com> > *Sent:* Wednesday, April 14, 2021 4:58 AM > *To:* Daniel Migault <mglt.i...@gmail.com>; Ace Wg <ace@ietf.org> > *Subject:* Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - > AS communication > > Hello Daniel, > > One thing I didn't have a chance to ask yesterday in the interim was about > the registration of the 'ace+json' application type. > Francesca brought this up as the MQTT profile describes the HTTPS > interactions differently than the core draft which says " When HTTP is > used as a transport then the client makes a request to the token endpoint > by sending the parameters using the "application/ > x-www-form-urlencoded" format with a character encoding of UTF-8 in the > HTTP request entity-body, as defined in section 3.2 of [RFC6749]." > > As I discussed with Francesca, we had discussions on the mailing list with > Jim using ace+json as well. I recalled the view that the draft that > introduces it should register it - I want to check if this is the general > agreement, or you (or the group) has a different view > - (1) registering this new type, or (2) MQTT draft is modified to > comply with framework description > - do we still agree that (1) it should be the MQTT profile > registering it or (2) it should be done elsewhere? > > Kind regards, > --Cigdem > > On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault <mglt.i...@gmail.com> > wrote: > > Thanks for the update, that works for me. > > Yours, > Daniel > > On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul <cigdem.sen...@gmail.com> > wrote: > > Hello Daniel, > I propose the following change to clarify the TLS use - if you are happy > with it, I will update the document: > > To provide communication confidentiality and RS authentication to MQTT > clients, TLS > > is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes > > the same assumptions as Section 4 of the ACE framework > > [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with > > the AS and setting up keying material. While the Client-Broker > > exchanges are only over MQTT, the required Client-AS and RS-AS > > interactions are described for HTTPS-based communication [RFC7230], > > using 'application/ace+json' content type, and unless otherwise > > specified, using JSON encoding. The Client-AS and RS-AS MAY also use > protocols other than HTTP, e.g. Constrained Application Protocol > (CoAP) [RFC7252] or MQTT; it is recommended > that TLS is used to secure the communication channels between > Client-AS and RS-AS." > > Since it is in this paragraph, one thing that Francesca brought up to do > is to register the 'application/ace+json' content type. > Kind regards, > --Cigdem > > On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault <daniel.migault= > 40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > > > Now that the authz document is being consolidated, I do have some minor > concerns regarding the recommendations mentioned in the profile documents, > that might require an additional update. > > The update to the authz document indicates more more clearly than before > that profiles need to provide some recommendations for the RS – AS > communication. > > > > “”” > > Profiles MUST specify for introspection a communication security protocol > RECOMMENDED to be used between RS and AS that provides the features > required above. “”” > > > > It seems to me the MQTT profile text makes it pretty clear that TLS is > recommended for all communications but I am wondering if additional > clarification would be beneficial – see below. That said I agree this is a > very minor point in this case that could be handled by the RFC editor. > > For the OSCORE or DTLS profiles, unless I am missing the RS – AS > recommendations in the documents , it seems to me it has been omitted and > needs to be added -- see below. > > > > > > Yours, > > Daniel > > > > ## MQTT - draft-ietf-ace-mqtt-tls-profile-10 > > > > “”” > > To provide communication confidentiality and RS authentication, TLS > > is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes > > the same assumptions as Section 4 of the ACE framework > > [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with > > the AS and setting up keying material. While the Client-Broker > > exchanges are only over MQTT, the required Client-AS and RS-AS > > interactions are described for HTTPS-based communication [RFC7230], > > using 'application/ace+json' content type, and unless otherwise > > specified, using JSON encoding. > > “”” > > > > I am wondering if that would not be more appropriated to specify in the > first line RS and AS authentication or simply authentication. > > > > > > > > > > - OSCORE draft-ietf-ace-oscore-profile-16 > > “”” > > This > > profile RECOMMENDS the use of OSCORE between client and AS, to reduce > > the number of libraries the client has to support, but other > > protocols fulfilling the security requirements defined in section 5 > > of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as > > well. > > “”” > > > > > - DTLS draft-ietf-ace-dtls-authorize-15 > > > > “”” > > It is RECOMMENDED that the client > > uses DTLS with the same keying material to secure the communication > > with the authorization server, proving possession of the key as part > > of the token request. Other mechanisms for proving possession of the > > key may be defined in the future. > > “”” > > > _______________________________________________ > 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 > > > > -- > Daniel Migault > Ericsson > >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
