Make invite acceptance response and request for share use http-sig always#384
Conversation
| the Receiving Server would not be able to verify the signature without | ||
| having access to the shared secret in advance. | ||
|
|
||
| ## Verification Requirements |
There was a problem hiding this comment.
adding a short mention of Accept-Signature (Section 5.1 of RFC 9421) as a wayn for verifier to state which parameters they require and support seems relevant in this section
There was a problem hiding this comment.
Is this needed since we have the http-sig capability in the discovery, already negotiating this? Do you know if it is usually is used by software libraries to prepare signatures, or if it would be redundant in this context given our discovery mechanism?
The tag is part of the signature, where as a label is only a dictionary key that MAY be rewritten by intermediaries.
Make ed25519 recommended for signatures and sha256 mandatory for hash algorithms.
We want signatures to always be used when they can be
|
I have now tried to describe the consensus about signature applicability and backwards compatibility in such a way that the spec allows incremental adoption. |
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
Modulo the last unresolved conversation, for which I don't have a strong opinion, this change is good to go and very welcome for me.
glpatcern
changed the title
3 participants
No description provided.