Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07

[Wolfgang Beck <[e-mail]>]

You explanation matches my understanding. See my mail to Martin why you
still can have two user  dialogs with your idp.  And the life time of your
idp's cookies can be shorter than the liftetime of the webrtc  server's
session cookies.

Wolfgang Beck
Am 06.11.2013 00:35 schrieb "Max Jonas Werner" <[e-mail]>:

> Wolfgang,
>
> On 05.11.2013 23:03, Wolfgang Beck wrote:
> > According to the draft and the w3c doc, the Idp exchange is completely
> > hidden from the JS. I don't see how a web server could use the result to
> > verify the user without looking at the SDP. Or how the peerconnection
> could
> > reuse the result of an Idp exchange that authenticated the user towards
> the
> > server. Did I overlook something?
> >
> > Having to log in twice will only be tolerated by a small minority of
> > people.
>
> I propose you read the draft again since perhaps you overlooked
> something. Let me give you an example:
>
> You have a WebRTC application that's served from your domain
> example.com. Perhaps you've implemented some kind of login mechanism so
> the user logs in (using an HTML form perhaps) resulting in e.g. a cookie
> being saved in the user's browser carrying a session ID (again, this is
> just _one_ possibility).
>
> Your application creates a PeerConnection object and calls
> setIdentityProvider with the parameter "domain" set to "example.com" and
> the parameter "protocol" set to "proto" because you want to be your own
> IdP. When creating an offer the browser will then load the code from
> https://example.com/.well-known/idp-proxy/proto into an iframe or such
> and send a message to that code asking for an assertion. Since the IdP
> proxy code is served from the same origin it may read out the cookie
> value set earlier when logging the user in.
>
> This cookie value can now be used on the server side to automatically
> (as in without user interaction) create an assertion since the server
> already knows who the user is (from the cookie).
>
> This also works with using another IdP (say Facebook) with your
> application served from example.com. If the user is already logged into
> Facebook: no interaction needed.
>
> Max
>
>