Re: [Wish] Authentication for resource url

[Juliusz Chroboczek <[e-mail]>]

> Using an username and password for authentication is very limited and for sure
> does not cover all the use cases for whip.

I understand that, and I am all in favour of people implementing better
authentication mechanisms.

What I am requesting here is an MTI authentication mechanism that
guarantees interoperability between independent implementations of WHIP.
In other words, I am asking for guidance about what I need to implement so
I can ensure that I interoperate with all WHIP clients, including those
that haven't been written yet.

> * Generate a unique random token, associate it to a stream/account on your
>   service and persist it on db or similar

What procedure do you suggest for securely communicating the token to each
user?  The obvious solution would be to make it available over HTTPS
protected by HTTP Basic, but then, we might as well cut out the middleman
and use HTTP Basic for WHIP.

> * Generate a signed jwt containing the stream/account information which does
>   not require to be persisted on the db,  then use a generic url
>   /whip/endpoint for all the requests and extract the stream info from the jwt
>   once the signature is validated

I assume this implies that the client is generating the token in
a compatible manner.  If we want to ensure interoperability, we need to
normatively reference a document that describes the procedure.

> * Generate a custom token (like base64(${username}:${password})),  then use a
>   generic url /whip/endpoint for all the requests and extract the stream info
>   from the token. [insecure]

I wouldn't be opposed to implementing that, but, again, this implies that
the client is generating the token in a compatible manner.  So we need
a normative reference so we can ensure interoperability.

-- Juliusz