Create a reserved prefix or delimiter for serialization of typed suborigins

[hillbrad]

Imagine in the future we create different criteria for entering a suborigin, beyond just declaring a name-as-a-string in a header.

For example, a "strong named" suborigin, in which the suborigin is defined as the sha256 hash of the resource. Or a signed suborigin, in which the name is a key fingerprint and content must also provide a valid signature with that key to enter the suborigin. (These types of suborigin might additionally enforce certain CSP script-src and require-sri-for policies on that content so as to provide a building block for verifiable/transparent applications.)

Those can be accomplished relatively easily by declaring a new header or options, but there still may be a need to have a serialization of such a suborigin to identify it to other components, e.g. to be able to postMessage with a strong-named or signed suborigin, or to store an origin bound key in WebCrypto that only such a suborigin can access.

It would be lovely if we defined some kind of reserved prefix or delimiter (like xn-- in DNS land) so such future possibilities remained open.

[devd]

agreed. I think we can prefix something after #38 is resolved.

[devd]

@hillbrad does #62 mitigate your concern or do you think we should instead do a "UAs must supports suborigins beginning with __ but web application authors should be aware that these might get typed later" ? (replace __ with "numbers" if you want)

[hillbrad]

That works. As I think about it more, the backwards compatible way to add the feature I'm thinking of is more likely another header that modifies the suborigin behavior, so that graceful fallback is possible.