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

From: Wolfgang Beck <[email-masked]>
Date: Tue, 5 Nov 2013 18:06:25 +0100

What I am missing in this draft is the link between authentication towards
the web server and signing of DTLS info towards the remote party. To make a
call, a user will have to
1) log into the web server application
2) permit the browser to access camera/mic
3) log into the IdP to sign the DTLS info

To receive a call, I will have to
1) log into the web server application
2) permit the browser to access camera/mic when there is a call
3) log into the IdP to sign the DTLS info
..and hope the caller has not given up before I clicked all permission
boxes and entered all user credentials.

Can 1) and 3) be merged somehow? How would you explain 3) to a user?

Wolfgang Beck

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 10:56:18 -0800

Most of the heavy login-related interactions can be moved earlier in
the process.  That is, before the call commences.

Keep in mind that you are sitting on a page, logged in to the site of
choice, when you are making or receiving a call.

On 5 November 2013 09:06, Wolfgang Beck <[email-masked]> wrote:
> ..and hope the caller has not given up before I clicked all permission boxes
> and entered all user credentials.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Max Jonas Werner <[email-masked]>
Date: Tue, 05 Nov 2013 21:58:24 +0100

Wolfgang,

> Can 1) and 3) be merged somehow? How would you explain 3) to a user?

1) and 3) can be merged if

a) the user is already logged from the IdP's point of view prior to even
visiting the site (using either built-in browser logic or manually)

or

b) the IdP is the able to identify the user from step 1) somehow (e.g.
when the web server is run by the IdP).

Keep in mind, though, that the user to be able to provide an identity to
the other WebRTC peer that is different from the identity of step 1) is
exactly what the user wants sometimes.

Max

---

From: Wolfgang Beck <[email-masked]>
Date: Tue, 5 Nov 2013 23:03:54 +0100

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.

Wolfgang Beck

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 15:38:29 -0800

On 5 November 2013 14:03, Wolfgang Beck <[email-masked]> wrote:
> Having to log in twice will only be tolerated by a small minority of people.

That assumes that the login is not persistent.  I believe that there
are plenty of options an IdP can use to ensure that this doesn't
become necessary.

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 6 Nov 2013 01:36:28 +0100

I'm not convinced. How would you explain to the user why he has to login --
or select an idp -- twice? Maybe this is more an API/W3C topic.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 17:37:21 -0800

> or select an idp -- twice? Maybe this is more an API/W3C topic.

As I have said a couple of times already, the user should not have to
login more than once.  If that were the case, then that would be a
problem with the IdP.  The generation of an assertion might require
login, but validation definitely shouldn't.

It's also possible that you already have a session open with your IdP.
 In that case, you wouldn't necessarily see a login flow at all.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 05 Nov 2013 17:44:11 -0800

>   In that case, you wouldn't necessarily see a login flow at all.

+1

I've been working on IdPs and WebRTC recently, and I also don't see why 
double login would be necessary. Where does this idea come from?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 6 Nov 2013 03:00:08 +0100

The draft proposes a solution where the peerconnection object does an idp
exchange of its own. The JS is kept out of the loop. It's not implemented
yet.

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 6 Nov 2013 03:15:51 +0100

What if the server requests a different set of meta data from the idp than
the peerconnection object? The idp will have two ask for permission twice.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 18:41:40 -0800

> the peerconnection object? The idp will have two ask for permission twice.

The number of questions the browser asks the IdP is completely
independent of the number of times that the user is required to log
in.  If you are both generating and validating assertions with the
same IdP, you can ask it twice.  THe validating IdP does not require
login.

---

From: Max Jonas Werner <[email-masked]>
Date: Wed, 06 Nov 2013 09:35:53 +0100

Wolfgang,

> Having to log in twice will only be tolerated by a small minority of

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

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 6 Nov 2013 14:45:33 +0100

Let's say the user authenticated with my webrtc service using google
openid. The webrtc server asked for the attribute 'display name'. The
OpenID server asks the user:'Can I tell webrtc server your display name
y/n?'. Now the peerconnection object asks the openid server for
authentication and the attribute 'email address', to get an rfc822 style
name it can return to the JS. This is a new permission the user has to
grant. And I dont know which openid attribute the peerconnection obj is
going to use. It can even change dynamically when google changes the
.well-known/idp document.

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 6 Nov 2013 14:59:12 +0100

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Nov 2013 11:14:27 -0800

On 6 November 2013 05:45, Wolfgang Beck <[email-masked]> wrote:
> Let's say the user authenticated with my webrtc service using google openid.
> The webrtc server asked for the attribute 'display name'. The OpenID server
> asks the user:'Can I tell webrtc server your display name y/n?'. Now the
> peerconnection object asks the openid server for authentication and the
> attribute 'email address', to get an rfc822 style name it can return to the
> JS. This is a new permission the user has to grant. And I dont know which
> openid attribute the peerconnection obj is going to use. It can even change
> dynamically when google changes the .well-known/idp document.

This is, overall, correct.  However, do you think that you have to
login every time that you load or reload a webpage?

---

From: Wolfgang Beck <[email-masked]>
Date: Thu, 7 Nov 2013 01:04:45 +0100

Probably not. It depends on the idp and browser settings. I'd rather fix
the problem than limit the frequency of its ocurrence. Maybe it's as easy
as having way for  the webrtc server to determine  what attributes the
idp-proxy is going to request, so it could 'prefetch' it.
Am 06.11.2013 11:14 schrieb "Martin Thomson" <[email-masked]>:

> openid.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Nov 2013 16:37:51 -0800

On 6 November 2013 16:04, Wolfgang Beck <[email-masked]> wrote:
> Probably not. It depends on the idp and browser settings. I'd rather fix the
> problem than limit the frequency of its ocurrence. Maybe it's as easy as
> having way for  the webrtc server to determine  what attributes the

There is always a possibility for prefetching user authentication
(with some caveats below).  However, it is only possible to acquire
the assertion after generating an identity assertion.  If you have
done the authentication prior to the call, then the call can proceed
without bothering the user.

The nature of the "log in" experience on the web is highly variable
and flexible.  The class of IdPs that we are talking about currently
use have relatively long-lived authentication cookies, so I would
consider it unlikely that these IdP interactions would require user
interaction, as long as the last login to the IdP - for any reason -
was relatively recent.

For example, if you use Facebook as your IdP and you've been to
Facebook recently, then I'd expect that the IdP would just proceed
maybe after a one-off authorization for the user agent).

And, just in case there is any confusion on the subject, validating an
assertion does not necessarily require that a user log in.  A Facebook
IdP could be used to validate an assertion generated by Facebook,
regardless of whether the relying user is a Facebook user.

The caveat: There is an open question with respect to discovery or
configuration of IdPs.  For what I hope are obvious reasons, we need
to ensure that the identity IdPs are not made public.

That means that an application will be unable to guarantee that a user
is logged in when the call is initiated.  The upshot of that is not so
serious as you might think.  If I read our current discussions
correctly, we are headed toward a situation where calls can be setup
without the identity mechanisms being complete.  (Note to self,
examine trickling identity.)

---

From: Max Jonas Werner <[email-masked]>
Date: Thu, 7 Nov 2013 12:12:47 +0100

> examine trickling identity.)

Interesting. Currently the API spec demands that upon creating
offers/answers an identity assertion is requested. Trickling this process
would mean re-negotiation of the call using updated offers/answers, right?
I wonder how that would improve UX because the user would probably see
"identity of your peer is not verified" and some seconds/minutes later "now
I got the assertion and verified it".

Max

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Nov 2013 08:32:46 -0800

> I got the assertion and verified it".

The ability to negotiate codecs and complete ICE are pretty useful.
The actual user impact is that the caller sees black until the IdP
thing completes, information that an application might choose to
suppress.  What is interesting is that the called party can actually
send AND receive media (though sending depends on gUM), because the
calling party will likely have generated an identity assertion.
Validation is quick.  The problem is that the calling party cannot
render it.  That leads to a race: signaling of the identity assertion
vs the first hello.

The good news is that identity can be gotten out of the way prior to
call establishment with a data channel setup.