← back to v154 · private-verification-tokens
conformance · v154
v154 · private-verification-tokens — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
the-query-methods-exist |
Both document methods of the shipping token mechanism this proposal builds on. They are the only part of the area callable without an issuer, a token or a gesture. spec ↗ | script | … | |
a-valid-issuer-answers-rather-than-throwing |
A well-formed https origin must produce a boolean, not an error — a browser holding no tokens says false. Anything else would make the check unusable as a pre-flight. spec ↗ | script | … | |
an-untrustworthy-issuer-is-refused |
An issuer must be a potentially trustworthy origin. A plain http origin is rejected before any lookup happens, which is what stops an issuer being impersonated on a network you do not control. spec ↗ | script | … | |
the-request-carries-token-operations |
Operations ride on the request options bag rather than on a header, so a page cannot forge or copy one. Probed with a getter, which fires only if the member is read. spec ↗ | script | … | |
the-operation-vocabulary-is-enforced |
An unknown operation is rejected at the options-bag conversion, with a message naming the offending value. A silently ignored operation would leave a page believing it had sent something it had not. spec ↗ | script | … | |
a-known-operation-is-accepted |
The control for the assertion above: at least one operation must be accepted, or the rejection proves nothing about the vocabulary. spec ↗ | script | … |