Add the topOrigin field to the limited clientData verification algorithm

[agl]

I was asked to to the PR for this issue, without looking at the submitted PR, in order to avoid IPR issues that would arise from a change by a non-member.

The topOrigin field was added the the CollectedClientData, and the serialization algorithm, but not the verification algorithm. This PR addresses that.

Fixes #2102

The following tasks have been completed:

• Modified Web platform tests (link) (Doesn't actually check this bit of the text due to complexity of setting up the iframes, but adds a test for this serialization in general, which was the bigger existing omission.)

Implementation commitment:

(Omitting due to minor nature of the change.)

Documentation and checks

• Affects privacy
• Affects security
• Updated explainer

---

Preview | Diff

[emlun]

Maybe indent this to make it part of the preceding list item?

Suggested change

	Note: a non-null value for |expectedTopOrigin| will cause all {{CollectedClientData}} structures generated by previous versions of this specification to be rejected as previous versions did not serialize the [=top-level origin=].
	Note: a non-null value for |expectedTopOrigin| will cause all {{CollectedClientData}} structures generated by previous versions of this specification to be rejected as previous versions did not serialize the [=top-level origin=].

[emlun]

Also: with this procedure, there is no way to validate a client data with "crossOrigin":true but without a "topOrigin". I would like to just reference the L2 verification procedure as a fallback, but that won't actually work: this L3 procedure would reject an incorrect "topOrigin", but the fallback would accept that incorrect "topOrigin" since that attribute is ignored in the L2 procedure.

In additions to #2104 I addressed this by adding a Boolean requireTopOrigin parameter and making some verification steps conditional on that, i.e.:

1. Append 0x2c2263726f73734f726967696e223a (`,"crossOrigin":`) to |expected|.
1. If |expectedTopOrigin| is null:
    1. Append 0x66616c7365 (`false`) to |expected|.
1. Else:
    1. Append 0x74727565 (`true`) to |expected|.
    1. If |requireTopOrigin| is true
        or if 0x2c22746f704f726967696e223a (`,"topOrigin":`) is a prefix
        of the substring of |clientDataJSON| beginning at the offset equal to the length of |expected|:
        1. Append 0x2c22746f704f726967696e223a (`,"topOrigin":`) to |expected|.
        1. Append [=CCDToString=](|expectedTopOrigin|) to |expected|.

What do you think, is this worth addressing?

[zacknewman]

I very much think this is worth addressing. While the algorithm is more complex, it would be nice if the limited verification algorithm were backwards compatible when possible.

[zacknewman]

I was told that a PR would be accepted which is why I submitted #2104. I don't know what an "IPR" is; but if it is inappropriate for me to send PRs, then I apologize and will refrain from doing so in the future.

Edit

DuckDuckGo says "IPR" is intellectual property. I would be more than happy to sign something that waives any intellectual property rights that would otherwise be associated with my contributions whether in comment or PR form. My only goal is make the spec consistent and rigorous enough that one can implement it with little ambiguity—my formal education is in pure math, so it can be difficult for me when technical documentation is not quite as "precise" as I wish.

[agl]

The chair asked me to write a version of this without looking at the other PR for IPR reasons. It seems that the IPR issues are resolvable so closing this PR.