Re: [Wish] Authentication for resource url

[Matt Ward <[e-mail]>]

It may be trivial for you to wrap your head around as the author of the
spec and a strong engineer. However, I still feel quite strongly that
converting a community of broadcasters (with a wide range of technical
understanding) from RTMP => WHIP is easier if the protocol drops into
existing UIs with near 0 changes required.

Imagine working at Blackmagic or Teradek and seeing a requirement to add a
bunch of UI in addition to a whole new underlying protocol. I suspect
requiring even basic auth there will slow adoption.

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

> FWIW, I did implement the initial whip draft in OBS and doing the UX for
> configuring the oauth token is trivial. The problem with ffmpeg is not
> going to be the bearer token authentication neither.. ;)
>
>
> El lun, 13 sept 2021 a las 19:56, Matt Ward (<[e-mail]>) escribió:
>
>> AFAIK today, there's no "Auth token" input for any of the other services?
>> Have you found an ffmpeg output that supports bearer
>> authentication? Usually, more UI/params/config => more state => more
>> complex clients => longer time to integrate.
>>
>> I want every single box that supports RTMP today to add WHIP tomorrow
>> with minimal friction!  :)
>>
>> On Mon, Sep 13, 2021 at 10:55 AM Sergio Garcia Murillo <
>> [e-mail]> wrote:
>>
>>> 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
>>>>>>
>>>>>