Re: IdP issues (was: Needs to be more clearly described)

On Tue, Sep 18, 2012 at 7:26 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 18 September 2012 18:31, Harald Alvestrand <harald@alvestrand.no> wrote:
>> One reason it hasn't been done is probably that its use case was felt to be
>> not compelling.
>
> Um, what?
>
> That would be the use case that we've been discussing for as long as
> I've been involved in this.  You and I use untrusted site to mediate a
> call between us, but want to ensure that the call is private.  The
> pokerstars.net case, if that helps jog your memory.
>
> If you are able to do media from a remote peer securely, local
> loopback should be just the same.  You just prevent reading from the
> rectangle that displays the video.  Control extends solely to where
> the rectangle is shown.  In practice, I imagine that implementation
> would be much like the security constraints on a cross domain iframe.
> And yes, blocking other uses like canvas, recording, sampling, etc...
> would be necessary.

I agree that this is a relevant use case. There is some discussion of
this in draft-ietf-rtcweb-security-arch S 5.2, which describes two mechanisms:

1. The ability for the JS to relinquish access to a given media stream and
have that enforced by the browser.
2. The ability to have permissions granted to send media to a given identity.
[Note that I had assumed that this would be enforced by the PC part
of the system, but we could discuss that.]

Put together, these allow you to have a system where media is
sent to a given identity and only to that identity.

As you say, the tainting isn't difficult and the browser already needs it
for any cross-origin/mashu-; type case.

-Ekr

Received on Wednesday, 19 September 2012 03:31:29 UTC