Need Guidance on Notification Message Security OR Negotiation Protocol

The guidance on notification security is overly broad - the protocol should either have very specific guidance, ie directly specifying a notification security mechanism, OR should have a clear mechanism for negotiating / signaling a notification security protocol (in the same way you have the general auth mechanism field ["bearer"]

> [Asymmetric keys](https://google.github.io/A2A/#/topics/push_notifications?id=asymmetric-keys)
> A pair of private and public keys can be generated using ECDSA, RSA etc. These can be generated by the notification server or the remote agent.
>
> If the key pair is generated by the notification server, (ex. APNS), the private key needs to be supplied to the agent. The notification server should keep the public key to verify incoming request payloads signed by the agent using the private key.
> If the key pair is generated by the agent. Then there can be two options:
> The public key is manually provided to the Notification Receiver.
> Or the public keys can be provided by the agent through JWKS protocol.
> Agents can sign request payload using the private key and provide the request signature as a header. Or they can use JWT protocol to generate a token and provide that as a signature. Benefit of JWT protocol would also be that it standardises common fields like keyId, request timestamp.
>
> [Symmetric keys](https://google.github.io/A2A/#/topics/push_notifications?id=symmetric-keys)
> A simpler method can be that both notification server and agents use the same shared key to sign and verify. The notification server verifies the signature by re-signing the payload with the key. Again JWT can be used to generate the signature token.
>
> Asymmetric keys have an advantage as only the agent knows the public key and hence less chances of the key being leaked.