Construction of the “tips-view-uri” (DISCUSS from Roman)

[boucadair]

** Section 6.2. Construction of the “tips-view-uri”.

-- Under what circumstances would it be appropriate to use http (instead of
https) for the tips-view-uri for this new protocol mechanism? Why is http
needed? Could https be the only option? I appreciate that there is history of
an http URL from RFC7285 published in 2014, but has field experience continue
to dictate a need for this insecure approach for an entirely new service? If
it is needed would there be a away to express a preference for secure transport?

-- Is there any underlying assumption in how “tips-view-path” is constructed? I
asked because Section 9.3 says “An outside party that can read the TIPS
response or that can observe TIPS requests can obtain the TIPS view URI and use
that to send fraudulent ‘DELETE’ requests thus disabling the service for the
valid ALTO client. This can be avoided by encrypting the requests and
responses (Section 15 of [RFC7285]).” Observing the tips-view-uri is one way
to spoof the URI, but what if it could be guessed? Is there an assumption that
a unguessable random string is part of the path? As far as I can find, no text
explicitly says that, although the examples imply it. If the string is
guessable being encrypted doesn’t help but using some kind of authentication
would.