Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <[e-mail]> wrote:

>
>
> I believe in this case the architecture document needs to change, or
> clarify that this MUST refers to that the mechanism needs to be *able* to
> communicate such a URI, not that such a URI must always be communicated.
>
> The group has discussed this several times, and I believe the API doc
> reflects the consensus: while we aren’t tackling solutions for captive
> portals that don’t involve User Portal pages (future solutions using a more
> OS-driven experience and perhaps built in payment, etc), we want to allow
> the API JSON to be usable in those new models. Not all captive networks
> will necessarily use this kind of URI in the future, and there’s no need to
> make the registry lock that in as mandatory.


Very well, I’d like to hear from one of the chairs, but if confirmed I’m
happy to move my DISCUSS to -architecture.

>
> >
> > I am also confused by this sentence at the end of section 4.1 about
> failed
> > authentication: “It may still be possible for the user to access the
> network by
> > being redirected to a web portal.”
> >
> > Who is doing the redirecting here? If authentication has failed, how is
> this
> > redirect authenticated and secure against theft of credentials?
>
> This is referring to the fact that the old HTTP redirect of a clear text
> webpage may still happen on a network. Even networks that support the API
> will need to handle legacy clients. This is only about redirecting
> unrelated pages to the user portal, and is orthogonal to the authenticity
> of the API server.
> >
>

Thank you for the clarification. I will move this bit to a COMMENT and
suggest “...access the network by redirecting a clear text webpage to a web
portal.”

>
>