-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying third party IdP for validating assertion #17
Comments
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 This is not a function that Say that I know you as |
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 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 For example when alice@example.net connects to bob@example.org, Alice's // 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 |
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). |
Initially raised by @soareschen at w3c/webrtc-pc#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 andRTCPeerConnection
does not care about local peer identity.For remote peer identity, the
domain
andprotocol
fields are used to construct the well-known URL for the IdP proxy. And if the IdP proxy returnsRTCIdentityValidationResult
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: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?The text was updated successfully, but these errors were encountered: