Specifying third party IdP for validating assertion

[dontcallmedom]

Initially raised by @soareschen at https://github.com/w3c/webrtc-pc/issues/1506

If my understanding is correct, setIdentityProvider() is used to set IdP proxy only for local peer identity. setIdentityProvider() can be set to any host and generate identity assertion for any domain, because the assertion is an opaque string and RTCPeerConnection does not care about local peer identity.

For remote peer identity, the domain and protocol fields are used to construct the well-known URL for the IdP proxy. And if the IdP proxy returns RTCIdentityValidationResult with identity belonging to different domain, it would result in error. But rtcweb-security-arch also mention about validating the identity against third party domain:

5.7.1. Identity Formats

2. If the domain portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless:
3. the IdP domain is trusted as an acceptable third-party IdP; and
4. local policy is configured to trust this IdP domain for the domain portion of the identity string.

So would there be any case in WebRTC that an IdP trusted as an acceptable third-party IdP that can produce RTCIdentityValidationResult for identities of different domains?

[dontcallmedom]

Comment by @martinthomson

I think that the question here is about how an IdP might make a claim about a different domain. Or, if you get an assertion for user@example.com, how example.net might verify that assertion.

This is not a function that setIdentityProvider is intended to provide. This is something that the browser might decide to allow, but a site wouldn't and indeed MUST NOT.

Say that I know you as soareschen@example.net. If I visit a site, I need to know that when the assertion arrives for you, then it is you. You don't want https://attacker.example to be able to install an override so that their IdP can assert for example.net.

[dontcallmedom]

Comment by @soareschen

My original question is whether custom IdP can be set when validating identity assertion. (It shouldn't, that's why seeking clarification for 5.7.1.2.). But AFAIK setIdentityProvideris for generating identity assertion and WebRTC do allows third party IdP to be used.

As far as my understanding in WebRTC there is currently no way for a browser to know about the local identity. It only knows the domain of the local identity but doesn't validate that it is the same as specified in setIdentityProvider().

For example when alice@example.net connects to bob@example.org, Alice's RTCPeerConnection doesn't actually know that she is in fact alice@example.net. Alice's RTCPeerConnection only knows how to call generateAssertion() from whatever IdP proxy that is specified in setIdentityProvider(), and the domain name example.net from RTCIdentityAssertionResult. It is only Bob's RTCPeerConnection learns that the assertion represents alice@example.net after calling validateAssertion() from example.net IdP proxy. In other words, Alice's app can do something like:

// Alice's app
pc.setIdentityProvider('alice-home-server.com')

// alice-home-server.com IdP proxy
// Somehows call example.net's custom API to get an assertion
// returns valid RTCIdentityAssertionResult for example.net
{
  idp: {
    domain: 'example.net'
  },
  assertion: 'string-signed-by-example.net'
}

So as long as alice-home-server.com returns valid domain and assertion, Alice's RTCPeerConnection is happy. Bob's RTCPeerConnection would of course contact example.net only and make sure that the validated identity alice@example.net also belongs to the same domain.

[dontcallmedom]

Comment by @martinthomson

This is correct, but I'm not seeing an issue here. Yes, one origin can produce an assertion that is validated by a different origin. Yes, the browser that is used to produce an assertion doesn't validate that assertion (it's not the relying party).

This might sound like a problem, but it isn't. You can read about why if you dig into SIGMA, and draft-ietf-mmusic-sdp-uks contains a more direct description of the problems that arise from this (and defenses you need).