Re: [Wish] Can a client switch tokens?

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

I only require authentication for the initial POST request, the
PATCH/DELETE security relies on the url randomness.

Note that tokens don't have any semantics in WHIP, so the expiration time
is something that you have decided to implement in Galene, and it should be
Galene the one who should decide what to do with expired tokens.

The client has no notion about it and won't know how to handle it.

Best regards
Sergio



On Sun, Jan 14, 2024 at 2:43 PM Juliusz Chroboczek <[e-mail]> wrote:

> > what do you mean by switch/update tokens?
>
> The client C requests a token T1.
>
> C uses T1 to create a WHIP session:
>
>   C->S: POST(T1) offer
>   S->C: answer
>
> An hour later, C decides to do an ICE restart.  However, T1 has expired.
> There are two possible client behaviours:
>
> 1. C uses token T1 for the ICE restart, even though it has expired:
>
>   C->S: PATCH(T1)
>
> 2. C requests a new token T2, and uses the new, unexpired token:
>
>   C->S: PATCH(T2)
>
> In case 1, the server needs to allow the client to use an expired token
> with a WHIP session, as long as the token is identical to the one used for
> creating the session.  This is easy to implement, both on the client (the
> client never renews a token) and on the server (the server retains the
> original token in the data structure that represents a WHIP session).
>
> In case 2, the server needs to allow the client to use a different token
> for PATCH requests than the one used during session creation.  There is
> also the need to communicate to the client the information that a token
> has expired.  I have no idea how to implement case 2.
>
> Galene currently uses approach 1, it stores the token used for session
> creation and allows it to be reused for PATCH even when it has expired.
> Is this the intended behaviour for a WHIP client?  If it is, then I think
> we need to document (possibly in an informational appendix) that a PATCH
> request may use an expired token.  If it is not, then please explain the
> intended behaviour.
>
> -- Juliusz
>