Relations with Signed Exchanges

[ioggstream]

I expect

To clarify the relations b/w message signatures and Signed Exchanges

Note

Similar headers are:

Signed-Headers: contains a list of headers to be signed

Signature containing the following data

Signature:
 sig1;
  sig=*MEUCI..Y=*;
  integrity="digest/mi-sha256";
  validity-url="https://example.com/resource.validity.1511128380";
  cert-url="https://example.com/oldcerts";
  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
  date=1511128380; expires=1511733180,
sig2;
  ...

[jricher]

Now that the httpbis draft supports signed responses and signature negotiation, can these efforts be merged? @jyasskin any thoughts on this? Would be happy to start a larger thread on the mailing list to discuss, or propose an interim discussion.

[yaronf]

Note that both drafts are using an Accept-Signature header, which could become an interop issue.

[jricher]

https://datatracker.ietf.org/doc/html/draft-yasskin-http-origin-signed-responses expired in January 2021 and I don't believe there's any forward motion on it right now. @jyasskin , @mnot , @tfpauly -- can we close this issue as resolved/OBE?

[mnot]

Last I talked to @jyasskin, they weren't using Signature any more. Jeff - any lingering concerns here? Once this draft gets approved by the IESG, they'll be registered.

[martinthomson]

See WICG/webpackage#713

[jricher]

This seems to be fairly settled, though I do still see references to the yasskin draft and questions about it from time to time. We could mention that draft, along with the cavage draft and the oauth draft, in the section on implementation, but that would only provide back-links to the other specs and I'm not sure it's worth it.

Suggest we close without action.