Change:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc

Discussion:
2.5.1. Interaction start modes are specified by a string, which consists of <del> the start mode on its own, or by a JSON object with one required field and any number of optional parameters defined by the mode: </del> <ins> the start mode name on its own, or by a JSON object with one required field and any number of parameters defined by the mode. </ins> <del> Individual modes MAY define additional parameters to be required in the object. </del> <ins> Individual modes defined as objects MAY define additional parameters to be required in the object. </ins> This specification defines the following interaction start modes:

Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The type of binding used is indicated by the "proof" parameter of the key <del> object in key-format.  This parameter is formally specified by an object with at least the following member: </del> <ins> object in key-format.  Key proof methods are specified either by a string, which consists of the key proof method name on its own, or by a JSON object with one required field and any number of optional parameters defined by the method: </ins> <del> Individual methods MAY define additional parameters as members in this object. </del> <ins> Individual methods defined as objects MAY define additional parameters as members in this object. </ins> Values for the "method" defined by this specification are as follows: Additional proofing methods are defined by the IANA-key-proof- methods. <del> For example, the "httpsig" method can be specified with its parameters as: </del> <ins> In cases where a method's parameters can be set to omitted or set to default values, methods MAY be defined as both an object and a string.  For example, the "httpsig" method can be specified as an object with its parameters explicitly declared, such as: </ins> <del> If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: </del> <ins> The "httpsig" method also defines defines default behavior when it is passed as a string form: </ins> <del> The AS would map this to the equivalent expanded form as follows: </del> <ins> This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated using sha-512. </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would

7.3.1. <del> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </del> <ins> This method is indicated by the method value "httpsig" and can be declared in either object form or string form. </ins> <del> The covered components of the signature MUST include the following: </del> <ins> When the proof method is specified in object form, the following parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and the SHA-256 hashing algorithm for the content digest. When the proof method is specified in string form, the signing algorithm MUST be derived from the key material (such as using the JWS algorithm in a JWK formatted key), and the content digest algorithm MUST be "sha-512". When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered components of the signature MUST include the following: </ins> When the message contains a request body, the covered components MUST also include the following:

7.3.2. <del> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del> <ins> This method is indicated by the method value "mtls" in string form. The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to

7.3.3. <del> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jwsd" in string form. The signer creates a JWS RFC7515 object as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:

7.3.4. <del> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jws" in string form. The signer creates a JWS RFC7515 object as follows: </ins> To protect the request, the JWS header contains the following claims.