Original text:
in the IANA Named Information Hash Algorithm Registry [1]. If the "hash_method" value is not present in the client instance's <del> request, the algorithm defaults to "sha3-512". </del>  <del> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then </del>  encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. <del> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using </del>  URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated <del> using sha-512. </del>  All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and <del> the SHA-256 hashing algorithm for the content digest. </del>  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 <del> algorithm MUST be "sha-512". </del>  When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered

Reviewer comments:
To edit notification comments on pull requests, go to your .
Nothing more than yaron's feedback
From IETF115 comments: Change the default hash for interaction_hash to sha256, and change the MTI profile to use the same.
Please search for some remaining occurrences of "sha-512".

Revised text:
in the IANA Named Information Hash Algorithm Registry [1]. If the "hash_method" value is not present in the client instance's  <ins> request, the algorithm defaults to "sha-256". </ins>  <ins> For example, the "sha-256" hash method consists of hashing the input string with the 256-bit SHA2 algorithm.  The byte array is then </ins> encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value.  <ins> The "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using </ins> URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated  <ins> using sha-256. </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and  <ins> the SHA-512 hashing algorithm for the content digest. </ins> 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  <ins> algorithm MUST be "sha-256". </ins> When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered