> > > > 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. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
