Mike West

@domenic: Consider a service like Disqus, which would love to use something like this (and were big advocates for `@seamless`. They would not be interested in making themselves CORS-same-origin with...

Hey Martin! I agree that the question of what to sign is important. Discussions with folks planning on deploying this mechanism (@ddworken, @yoavweiss, @punkeel, etc) have generally landed on `unencoded-digest`...

> Oh dear, I completely missed that because I didn't realize that the field had been renamed. (The new name is worse.) Others thought the previous name was worse. 🤷...

> Sorry, maybe I should have been clearer: If the signature covers more stuff then I would prefer this to work. I don't think that we _need_ to cover more...

> That we might later decide to include something more is the only thing we protect by allowing for arbitrary other fields. We could even advise against exercising that option,...

> Are you using HTTP signing or not? If you are using it, then that spec will deal with the mechanics of validating signatures. As you noted elsewhere, that spec...

We've landed on being lax with both parameters and components; if Message Signatures supports it, we should too. Based on folks experimental experience, that doesn't seem like it's going to...

It doesn't sound crazy to me; if it's possible to ship compatibly, great. /cc @otherdaniel, who might be interested in poking at this since it's somewhat related to https://github.com/WICG/sanitizer-api.

Noting this as a potential enhancement (several years later...).

I think we should probably document deployment scenarios we expect developers to explore. Some systems will certainly benefit from multiple keys, other more monolithic applications seem likely to want to...