Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

[Cigdem Sengul <[e-mail]>]

Hello Hannes,

I will summarise below what I understood and clarify where I got confused
(which I tried to in the interim meeting)
 and then would need the group feedback for the next steps.

I became aware that the key distribution may be an issue after the
e-mail thread: "Transporting different types of cnf objects - CBOR vs JSON"
that spanned June-Oct, 2019, in the ace mailing list, where you wrote:
"We have standardized the transport of this additional information in ACE for
use with CoAP but for HTTP we decided to do the work on OAuth, where it got
stuck because the IoT-interested people are not there and the Web folks
want something else."

Then, I was under the impression that I would need to wait for the
draft-ietf-oauth-pop-key-distribution
<https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07>.
(Even though the prototype implementation I used worked with HTTP/JSON
equivalent for COAP/CBOR in draft-ietf-ace-oauth-authz )

That's why is responded to this email thread saying I am aware of the
issue.
After Jim's email, I understood that the issue may be resolved.

For the MQTT-TLS profile, the following is needed:
1) To be able to use HTTP to talk to AS for /token and /introspect
interfaces. I was aware that this was supported now
in draft-ietf-ace-oauth-authz:
    "If the RS is online, validation can be handed over to the AS using
token introspection (see messages D and E) over HTTP or CoAP".
    In 5.6 Token endpoint: "The endpoint may, however, be exposed over
HTTPS as in classical OAuth or even other transports."

2) mqtt_tls draft introduces the ace+json media type, as  Jim wrote: "I
would argue that the first draft using such a media type would be the
right place
to specify it. " in the thread "Transporting different types of cnf objects
- CBOR vs JSON".

3)  What I wasn't aware, and realised after Jim's email was that
draft-ietf-ace-oauth-params, which defines the cnf and rs_cnf
parameters say, supports JSON:
"Note that although all examples are shown in CBOR [RFC7049],
JSON [RFC8259] MAY be used as an alternative for HTTP-based
   communications, as specified in [I-D.ietf-ace-oauth-authz]."

I may be missing something but what is left for MQTT-TLS profile to define
when  draft-ietf-ace-oauth-authz  +   draft-ietf-ace-oauth-params put
together?


Kind regards,
--Cigdem








On Mon, Mar 9, 2020 at 8:01 PM Hannes Tschofenig <[e-mail]>
wrote:

> Hi Cigdem,
>
>
>
> Following the OAuth virtual interim meeting call today I wonder whether it
> makes sense to describe how the key transport with the PoP token using the
> communication between the client and the authorization server over the HTTP
> interface works.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* Hannes Tschofenig
> *Sent:* Friday, February 28, 2020 11:08 AM
> *To:* Cigdem Sengul <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [Ace] draft-ietf-ace-mqtt-tls-profile-03
>
>
>
>    - I plan to join. I  have been aware of the issue, but could not
>    follow how it was planned to be resolved.
>    - I was looking at this: draft-ietf-oauth-pop-key-distribution
>
>
>
> Yes, that’s what the group wanted to do. Now, new ideas showed up on the
> radar that are incompatible with that approach that offer a much tighter
> integration with HTTP signing.
>
>
>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>