This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The identity of the peer for an RTCPeerConnection is valuable information. Current work concentrates on the mechanisms for authenticating this peer and presenting identification information on browser chrome. No API surface is provided for inspecting the certificate presented by the peer. No API surface is provided for inspecting the certificate that will be presented to the peer. Providing access to certificates allows an application to make in-content assertions about the peer identity, as well as provide additional checks. For instance, an application might be unable to use peer identity, but can provide their own assurances about peer identity. In terms of what information is provided, this doesn't need to be robust. I don't know what the WebCrypto group has done so far on this, but taking advantage of any API defined there is probably sensible. At a minimum, this should provide access to the CN, DER-encoded certificate and a couple of certificate fingerprints (SHA-1 and SHA-256 probably).
(I forgot to add this.) Certificate information should be available even if the peer identity doesn't carry an identity assertion from an IDP. That means that the RTCIdentityAssertion probably isn't the right place to add this information.
Stats has defined stats items that allow access to certificates. Would these satisfy the issue? If so, we'll move this bug to be on stats.
Included in RTPSender proposal.
The API suggested is on the Transports proposal: Bug 27224.
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues Please subscribe to the issues you want to keep watching.