Re: [Wish] Authentication for resource url

I put this in
https://github.com/wish-wg/webrtc-http-ingest-protocol/issues/16 but here's
a quick cross post of my thoughts.

Today, we do rtmp://live.mux.com/app/{STREAM_KEY} and are imagining support
for WHIP via something akin to https://whip.mux.com/{STREAM_KEY}. In such a
case, this simple URL by itself contains what we believe to be sufficiently
"secret" information to secure ingestion (as we have done this same thing
for years in the RTMP world).

I've proposed an edit in
https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/17 clarifying
that "any HTTP compliant authentication and authorization MAY be
implemented" and that RFC6750 is an example.

On Sat, Sep 11, 2021 at 12:04 PM Adam Roach <adam@nostrum.com> wrote:

> On 9/11/2021 7:56 AM, Sergio Garcia Murillo wrote:
> > As said in a different email, we are not mandating the usage of oauth2.
> >
> > Anyway, in my implementation the token is a unique value that is
> > matched against database on the whip enpoint. Media servers don't have
> > access to that database.
> >
> > It doesn't harm my implementation to receive y
> > the token on the media server, but not sure if we should mandate it if
> > there are no plans for using it.
>
>
> Our infrastructure uses a bearer token (it's a cryptographically-signed
> assertion, so no database required), and it would be kind of a pain to
> require a securely random URL in addition to that. So I'm happy with the
> original formulation from your previous message, wherein the client must
> send the auth token, but the media server can use that or another
> mechanism (such as a sufficiently random URL) to validate that the
> operation is authorized.
>
> /a
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>