Re: [media-types] Notice of intended registration of "application/captive+json"

Hi,

I don't understand why you want to use(/register) as specific
application/captive+json and not simply application/json.
>From what I can see in the specification, you are not using that as a
"specific" file in itself.
It is just a standard json reply to a standard request without added value.

Regarding the capport-api, I don't know where would be the relevant place
for me to submit some remarks?
But I profit of this email to list of few of them that I have.
It is nice to attempt to fix the "captive portal" situation but I think
there a few things that could be improved.
1) There should probably be the current api version inside the reply (json)
2) There could probably be more fields that would be useful:
- network access when "captive" ie (before login): restricted, lan, wan,
internet
- network access when not anymore captive (after login): restricted, lan,
wan, internet
- If the network is restricted to using a specific dns server, and in that
case its address
3) MOST Important: You can't force HTTPS/TLS for such an usage!
- Most of the time, it will be an embedded consumer devices that can't get
easily a domain name and certificate.
- Client devices might not already be on a correct date/time, with updated
root certificates, as they might never have connected to internet without a
captive portal first.
- In the end, the captive portal can give you access to an internal network
that is not connected to internet
- As the client device will have no internet/dns connection before being
authorized by the portal, the captive-portal server will probably be
targeted by IP addr and not domain name.
(cf. RFC7710)
- I guess it will be the role of the "UX" to warn the user of the dangers
before doing any action if no TLS available.
Also:
- This rule was designed against man in the middle attack impersonating the
captive-portal.
But, in small structures that would not be able to offer TLS, we can assume
that if we are behind a captive-portal,
it is this captive portal that is in control of the network and the only
one in position to do man in the middle.

Regards,

Florent

On Wed, Apr 1, 2020 at 3:19 PM Darshak Thakore <d.thakore@cablelabs.com>
wrote:

> As per Section 5.1 of RFC 6838, we wish to notify the list of the intended
> registration of a new media type in the standards track document
> https://tools.ietf.org/html/draft-ietf-capport-api-06.
>
>
>
> Comments and feedback welcome.
>
>
>
> Regards,
>
> Darshak
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types
>