v154 · private verification tokens

The request option, validated

Token operations ride on fetch, in an options-bag member. That means they are validated at request construction — before any network activity, any issuer, or any token — so the whole grammar can be measured from a page that has none of those things.

Build one


    
Building…

    
    
Every combination is constructed for real. Nothing is sent — a Request object is built and discarded — which is exactly enough to find out whether the browser would have accepted it.

  


  

    
The grammar, measured

    

      
    

    

      

        Each option value, offered on its own
        
optionvalueaccepted?what the browser said

        
Not swept yet.

      

    

    
  


  

    
What a round trip would look like

    
// 1. Issuance — the site that already believes you are a person.
await fetch("https://issuer.example/issue", {
  privateToken: { version: 1, operation: "token-request" },
});

// 2. Later, somewhere else — the site that would otherwise challenge you.
await fetch("/protected", {
  privateToken: {
    version: 1,
    operation: "send-redemption-record",
    issuers: ["https://issuer.example"],
  },
});

    
Neither request carries anything you wrote. The browser attaches the token material and strips it from what your code can see, which is why this is an option on the request rather than a header you set — a header you could set is a header you could copy.

    
This page does not perform either request. There is no issuer to talk to, and firing a real token-request at a made-up origin would produce a network error that says nothing about the mechanism. The validation above is the part that can be measured honestly.

  


  
see also