On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <tpa...@apple.com> 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.” > >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
