Add RFC for JWS-signing PGXN releases

[theory]

No description provided.

[sjmiller609]

Normally a JWS is like headerB64.payloadB64.signatureB64, and therefore I am wondering about why the payload is separate from the header and signature. I believe it is like that in order to support multiple signatures.

Questions to consider are...

• is it necessary to support multiple signatures?
• For 'protected' and 'header', both of these parts typically included in the "header" as described in RFC 7515, so why not combine that into just 'header' as b64 encoded.
• Wondering because if you take the payload, the header (as suggested in previous comment), signature, and concatenate them with "." joined (RFC7515 section 3.3), then would that make it exactly like a "normal" signature? i.e. easier to use with existing clients that do signature validation maybe.

[theory]

It's an official RFC 7515 format called JWS JSON Serialization. We don't need URL-safe serialization, so this is just a little friendlier for clients. And yes, it allows multiple signatures, which could be useful for author signing or gradual key rotation.

1. I think it's useful to support multiple signatures because, unlike ephemeral HTTP requests, there's are records at rest and will be around for many years.
2. protected and header are not combined because the JWS JSON Serialization format separates them.
3. Clients should also support this format, as it's part of the standard. But even if they don't, conversion will be trivial, as you point out.

Really I wanted the payload not to be Base64 URL-encoded, as specified in JWS-JS, but I believe that spec was abandoned in favor of RFC 7515 JWS JSON Serialization, so going with that approved standard, instead.

[sjmiller609]

Embedding the public key in clients seems questionable to me, but looks good otherwise.

[theory]

Embedding the public key in clients seems questionable to me, but looks good otherwise.

Switched to talking about downloading and using a JWK Set in 01140f3.