Re: [Wish] Authentication for resource url

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

Not sure how an RTMP implementation may affect how OBS or ffmpeg implements
WHIP, should be as simple as this:

[image: image.png]

El lun, 13 sept 2021 a las 19:29, Matt Ward (<[e-mail]>) escribió:

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