Re: [Wish] Authentication for resource url

[Matt Ward <[e-mail]>]

In the current abstract for WHIP, the spec comes out stating "Currently
there is no standard protocol (like SIP or RTSP) designed for ingesting
media in a streaming service, and content providers still rely heavily on
protocols like RTMP for it."

Why do content providers rely on RTMP and possibly more interestingly, why
do publishers/broadcasters/end-users love RTMP?

It is dead simple.

If our goal is to replace RTMP, I think we need to allow clients to be as
dead simple as RTMP is today. In order to do this, we must allow clients to
ship with support for only path based authentication as in RTMP. This will
require a minimal amount of UI/UX changes and speed time to support in many
broadcasting software/appliances.

As for MAY support beyond that, I'd look at how custom RTMP is configured
in OBS. To that end, it only supports authentication via basic auth. I
imagine adding support for bearer authentication that's only supported for
WHIP in OBS adds complexity to that client. I imagine this additional
burden would not be uncommon across the space of existing broadcasting
software/appliances. As for one more example, I have seen approximately 0
ffmpeg example commands outputting with bearer authentication.

[image: Screenshot from 2021-09-13 10-16-54.png]


On Mon, Sep 13, 2021 at 9:30 AM Sergio Garcia Murillo <
[e-mail]> wrote:

> I disagree with the approach.
>
> IMHO, using username/password authentication in http rest apis is insecure
> as it forces the user to store it's password into several "low security"
> applications and most service providers have deprecated it in favor of a
> token based authentication.
>
> My proposal would be that it is a MUST for clients to support
> authentication via the bearer token and it would be optional for the server
> to implement it or not. In case the user does not provision the token on
> the whip client, an unauthenticated request would be sent to the server.
>
> Best regards
> Sergio
>
> El lun, 13 sept 2021 a las 18:14, Juliusz Chroboczek (<[e-mail]>)
> escribió:
>
>> > I understand the motivation, but this doesn't get us to
>> > interoperability. We need a baseline, mandatory-to-implement
>> > authentication method for both client and server; otherwise, we'll end
>> up
>> > in a situation where your client implements mechanism A, my network
>> > implements mechanism B, and your users can't use my network.
>>
>> Yes, and that is why I suggested HTTP Basic instead of bearer token.
>>
>> Most servers today implement authentication using a username/password
>> pair.  While this is certainly not the most secure solution, it is well
>> understood by users, and is therefore likely to remain the main mode of
>> authentication for the foreseeable future.
>>
>> With HTTP Basic, it is perfectly clear how to map a username/password pair
>> to the protocol.  With bearer token, the client and the server need to
>> both agree on how to map the username/password pair to a token, and
>> I expect different implementations to use different mappings, with all the
>> fun that this entails.
>>
>> So I suggest that for clients:
>>
>>   - support for unauthenticated WISH over HTTPS is MUST;
>>   - support for HTTP Basic over HTTPS is MUST;
>>   - other authentication methods is MAY.
>>
>> If that is not what Sergio has in mind, then the draft needs to mandate an
>> unambiguous and deterministic way of mapping a username/password pair to
>> an authentication method.
>>
>> -- Juliusz
>>
>