[webrtc-pc] Is contents validation based on exact string matching or fingerprint list matching when verifying identity assertion?

soareschen has just created a new issue for https://github.com/w3c/webrtc-pc:

== Is contents validation based on exact string matching or fingerprint list matching when verifying identity assertion? ==
There are a few places that mention that `contents` returned by `validateAssertion` must be exact string match of `contents` passed to `generateAssertion`:

> Callback GenerateAssertionCallback Parameters
> contents of type DOMString
>   The contents parameter includes the information that the user agent wants covered by the identity assertion. A successful validation of the provided assertion MUST produce this string.

> Dictionary RTCIdentityValidationResult Members
> contents of type DOMString, required
>    The payload of the identity assertion. An IdP that validates an identity assertion MUST return the same string that was provided to the original IdP that generated the assertion.
>    The user agent uses the contents string to determine if the identity assertion matches the session description.

And in rtcweb-security-arch:
> 5.7.  Verifying Assertions
> contents:  The original unmodified string provided by the AP as input to the assertion generation process.

However in section 9.4 Verifying Identity Assertions, `contents` is validated by only decoding it and match against all a=fingerprint attributes.

> 9.4 Verifying Identity Assertions
> 8. The RTCPeerConnection decodes the contents and validates that it contains a fingerprint value for every a=fingerprint attribute in the session description. This ensures that the certificate used by the remote peer for communications is covered by the identity assertion.

This means it doesn't need to be exact, e.g. there can be extra fingerprints in `contents` or fingerprints can be reordered.

Other than that, there are issues on enforcing either of the requirements.

For exact string matching, this is not possible because the original `contents` is only known by the remote peer, and there is no additional metadata in the SDP that mention what the original `content` must be. We cannot rely on the a=identity line because the assertion string returned from the IdP is opaque, and may not contain the original `contents` string, e.g. it can be stored on server side.

For fingerprint list matching, `contents` is supposed to be an opaque string and rtcweb-security-arch doesn't specify what should be the format of `contents`. In other words the format could be implementer specific and thus could introduce interoperability issues.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1505 using your GitHub account

Received on Monday, 24 July 2017 09:01:04 UTC