Repository navigation
Conversation
Adds a `set_signing_alg_values_supported` property to the Transmitter Configuration Metadata and a Receiver-supplied `set_signing_alg` property to the Stream Configuration, so a Receiver can discover which JWS algorithms a Transmitter supports and select the one used to sign SETs on a stream. Receivers are required to verify the SET `alg` header against the negotiated value. This is written against the 1.0 document only to give the working group a concrete diff to review. I suggest it lands in SSF 1.1 once the 1.1 draft documents exist. Relates to #350
|
This will bring too much dependence of signing in the SSF metadata and I don't support this approach. SET spec handle signing aspects |
Can you explain what you mean please? Is the only alternative to this is that every transition of algorithms is handled manually for each stream or are there other options? |
Sorry, adding more clarity. I don't think SSF needs a negotiation mechanism, because the key layer plus the CAEP interop fix in #356 already covers this. For EC and Ed25519 keys, the key fixes the algorithm (crv: P-256 means ES256, Ed25519 means EdDSA; RFC 7518 3.4, RFC 8037 3.1). For RSA keys, the JWK alg (RFC 7517 4.4) says whether it's RS* or PS*. Where a Transmitter doesn't publish alg, #356 will cover it. I think, that keeps deployments flexible without adding normative requirements to SSF. Also, keys are per transmitter, adding per stream options for key neg will make it complex. Algo change can be handled by key by publishing new key, sign with its kid, and keep the old key until queued poll SETs drain. |
Adds a
set_signing_alg_values_supportedproperty to the Transmitter Configuration Metadata and a Receiver-suppliedset_signing_algproperty to the Stream Configuration, so a Receiver can discover which JWS algorithms a Transmitter supports and select the one used to sign SETs on a stream. Receivers are required to verify the SETalgheader against the negotiated value.This is written against the 1.0 document only to give the working group a concrete diff to review. I suggest it lands in SSF 1.1 once the 1.1 draft documents exist.
Relates to #350