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

[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