Re: [Wish] Authentication for resource url

[Juliusz Chroboczek <[e-mail]>]

>> To give an example of how this is done in production services: on Twitch,
>> once you log in, you go into account management, click on the "Stream"
>> tab, and copy a really long string of junk out of a field labeled "Primary
>> Stream Key." You paste this into your broadcast client in a field usually
>> named "Stream Key."

Just to be clear: I think token auth is a good idea, and as a matter of
fact Galene uses token auth for authentication to the TURN server.

What I'm arguing for is a simple, interoperable user/password mechanism
for the simple case, for when the infrastructure required to securely
communicate the token to the client is not deemed necessary.  My current
opinion (likely to change as Sergio and Adam explain stuff to me further)
can be summarised as:

  * HTTP basic: MUST implement in clients, MAY implement in servers;
  * token: SHOULD implement in clients, SHOULD implement in servers.
  
This way, server authors are guaranteed to interoperate with all clients
if they choose to implement HTTP Basic, and they can use the more secure
token auth if they are willing to put it the work required to build
the infrastructure required to communicate tokens to their chosen clients.

This way, WISH is useful both for Millicast, whose business model relies
on helping users deploy their high-quality broadcasting solutions, and for
free servers such as Galene, who want to minimise the amount of hand-holding
that they need to provide to their non-specialist users, even if that
implies not using the most secure authentication techniques available.

-- Juliusz