Re: [Wish] Authentication for resource url

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

I agree that the wording in the current draft and the reference to the  RFC
6750 is not clear at all, I will try to improve on the next versions of the
draft.

I have tried to explain different usages of the auth token in a response to
a former email by Juliusz explaining how the service could make use of it
in different ways.

However, not sure how much of that info should be in the draft as the
examples are not normative but implementation specific.

Best regards
Sergio

El mar, 14 sept 2021 a las 0:31, Cameron Elliott (<
[e-mail]>) escribió:

>
> I think I appreciate (I hope anyway) what Matt and Juliusz are getting at.
>
> Well, from my perspective, it seems to be the idea that authentication
> should be easily understandable and grasped by
> developers who are NOT OAuth familiar, and NOT RFC 6750 familiar, and even
> non-developer end-users also.
> This sounds like a great goal.
>
> From my perspective the RFC 6750 makes things unnecessarily complicated.
> Well maybe it's necessary
> in the context of OAuth, but for non-OAuth usage, it seems complicated.
>
> I totally understand, it might not be clear how to do super-simple
> end-user auth without OAuth using the short description
> in the draft.
>
> But the nice thing about a bearer token approach, is it can support all
> the different models that have been discussed.
> - OBS stream-key
> - username/password (well password-only)
> - The different OAuth models
>
> Again, I think the criticisms from Matt & Julius make sense, it's not
> clear how to use RFC 6750 in even
> the most basic way, unless you have a certain amount of experience around
> using bearer tokens for auth.
> (I will note, bearer tokens are the most common way to authenticate APIs
> these days, not username/password)
>
> Maybe what is needed are two simple examples in the spec that show how
> bearer tokens would be used:
> 1. concrete example comparing how it can be used as an alternative to
> username/password. (http basic auth alternative)
> 2. concrete example comparing how it can be used as an alternative to
> passing stream-keys in the URL.
>
>
> Might really go a long  way to making it clear how to do auth in non-oauth
> scenarios where 'http basic auth' or
> 'url based stream keys' have been used previously.
>
>
>
> Cameron
>
>
>
>
> On Mon, Sep 13, 2021 at 11:22 AM Matt Ward <[e-mail]> wrote:
>
>> 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
>>>>>>>>
>>>>>>> --
>> Wish mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/wish
>>
>