Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

[Kyle Larose <[e-mail]>]

David,

On Wed, 27 Mar 2019 at 08:26, David Bird
<dbird=[e-mail]> wrote:
>
> This is assuming that DHCP and RA will be handing out unique URLs to UEs encoded with the necessary token identifying the UE.
>

At IETF 100 we discussed how the various components interacting with
the captive portal would be identified.
One of the methods was "implicit" identification -- i.e. rely on the
source MAC, IP, etc. to identify. If the API
end-point is located such that this is feasible, then the DHCP/RA
won't need to encode the identity in the URL.
That said, this does restrict where the API could be, unless the
Enforcement Device can tunnel the request
to the API with some form of identifying characteristic contained in
the encapsulation's metadata, or someone
figures out a simpler technique to securely augment the request with
the necessary info. I'm not sure how people
feel about that, or whether it is truly feasible.

> If that is not possible, then the URL is likely to be anything outside the walled garden so that the API end-point gets caught up in the existing HTTP redirection to get the right UE specific URL.

To clarify, you mean *not* likely, right?

Overall, I don't think (correct me if I'm wrong) we're saying that the
captive portals will immediately stop doing
the redirection. Rather, they will likely continue to support that
until a critical mass of UEs support the new
mechanisms.