Is contents validation based on exact string matching or fingerprint list matching when verifying identity assertion?

[soareschen]

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. (Update: format for `contents is specified in 5.6.4.)

[martinthomson]

I don't understand the question.

[soareschen]

Oops, I missed rtcweb-security-arch section 5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions which specifies the format of contents, which caused the entire misunderstanding.

In that case I just need one clarification: Is reordering or reformatting of the fingerprints in content allowed? For example:

const contents1 = `{
 "fingerprint": [ {
   "algorithm": "sha-256",
   "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
 }, { 
    "algorithm": "sha-1",
   "digest": "74:E9:76:C8:19:...:F4:45:6B"
 } ]
}`

// Reformatting and reordering of contents1
const contents2 = `{
 "fingerprint": [ 
    { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" },
    { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" } 
  ]
}`

If on peer1's generateAssertion() receives contents1 and peer2's validateAssertion() returns contents2, is that valid? Section 9.4.8. in webrtc-pc allows it, although everywhere else says validateAssertion() MUST return the original contents1 string.

[martinthomson]

The contract specifies contents as being opaque. That should be enough for you. We might later want to rely on that property and include something entirely different. Allowing mutation of the contents would make that difficult.

[soareschen]

My point is that string equality cannot be enforced as a MUST in the spec. At most it can only be a SHOULD requirement. The original contents string is not in the a=identity line of SDP and so is not passed over to the remote peer. Therefore a remote RTCPeerConnection can only do content-based fingerprint matching as specified in 9.4.8.

[martinthomson]

You could write a test case for an IdP that enforces this constraint and it's an important invariant.

[soareschen]

Hmm ok. So we can say that IdP proxy scripts MUST treat contents as opaque string and return the same string during validation, but it is outside the scope of WebRTC to enforce the requirement.