On Tue, Nov 27, 2018 at 11:03 AM Emad Omara <emadomara@google.com> wrote: > Worth mentioning that as I pointed out during my presentation in TPAC > these APIs could be generic APIs to process/transforms encoded frames, and > it is up to the application to write their own transformation including > encryption. > Sure, but we're discussing the motivating use cases. -Ekr Emad > > On Tue, Nov 27, 2018 at 2:28 AM Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> On 26/11/2018 19:59, Adam Roach wrote: >> > On 11/25/18 4:16 PM, Sergio Garcia Murillo wrote: >> >> That the IdP script is trusted, so I don't see any reason why it >> >> can't handle the keys. >> > >> > >> > This doesn't make any sense. There's nothing that prevents the domain >> > hosting the application JavaScript from pointing to its own IdP (or an >> > IdP under its control) using setIdentityProvider() -- which has the >> > exact same security properties of handing the key to itself under your >> > proposal. >> >> No, because the browser will show the domain on the prompt and you will >> know who you do trust. If not IdP would be completely useless. >> >> > >> > The IdP is trusted to do one very exact and precise thing. Media key >> > handling is very different than identity assertion. >> > >> Why? Idp can say: remote peer is "Sergio Garcia" and this is his public >> key so you can send media to him (on top of dtls keys that are exchanged >> normally and not available to the app) >> >> Best regards >> >> Sergio >> >> >> >>
Received on Tuesday, 27 November 2018 23:29:26 UTC