Re: [Wish] Authentication for resource url

[Sergio Garcia Murillo <[e-mail]>]

I think this is root cause of the confusion, the client does not generate
or retrieve the token anyhow.

The server/service makes it available to the user somehow (out of the scope
of this document) and the end user configures it on the client (alongside
with the whip url):

[image: image.png]

Best regards
Sergio

El mar, 14 sept 2021 a las 13:18, Juliusz Chroboczek (<[e-mail]>)
escribió:

> > 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
>