On Sun, Jun 21, 2020 at 12:24:30PM -0700, Erik Kline wrote: > > > > > Without knowing the details of the particular solution, it's a bit > > > > > hard to say for sure, but roughly > > > > > I'd say it's someone who wants to interact with the API using the > > > > > identity of the user. E.g. if we're using an 'unguessable' URI, an > > > > > attacker snooping on the communication with the API could determine > > > > > the URI, and use it. > > > > > > > > > > Does that sound reasonable? > > > > > > > > That seems like it's in the right ballpark. I guess both the API URI > > > > and > > > > the web portal URI could be "unguessable" (though both would be > > > > protected > > > > by the same TLS connection, at least for the UE/API part of things). > > > > > > > > > > Tommy raised an objection in the issue > > > (https://github.com/capport-wg/architecture/issues/95) I submitted on > > > github for this. Initially, > > > I said that the API URI should be unguessable. I conflated the two > > > types of URI when I > > > wrote my initial reply. To clarify, I'm now planning only suggesting > > > that the user portal URI > > > be unguessable. > > > > That makes sense; there could be some value in having the API URI be > > consistent (notably, in not having to track devices at as low a level), and > > making it unique only starts adding value for the user-poral URI. > > > > > I'll repeat my earlier question: does anyone else have an opinion on > > > this? I feel like it could > > > be controversial, since it could add complexity to the solution, but I > > > do think it could help. > > > > Perhaps the chairs, at least, could weigh in? > > I'm slightly unclear on what "unguessable" means in this context. If > it means unique to a client, then the API URI should not be > per-client. This is because the IPv6 RA option is multicasted to all > clients on the link and cannot reasonably be made per-client.
It's something stronger than unique per client, and yes, we're not going to make the API URI unguessable. Thanks for checking! -Ben _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
