applied mike's suggestion

Co-authored-by: Michael B. Jones <[email protected]>

openid-4-verifiable-presentations-1_0.md

@@ -444,7 +444,7 @@ The following is a list of methods defined by this specification that MAY be use
 - Pre-registered: If the Client is pre-registered, the `jwks` Client Metadata parameter provided upon registration MUST be used to verify the signature of the Request Object. The `redirect_uris` Client Metadata parameter is used to verify the `redirect_uri` or `response_uri` for that Client. Note that the Wallet determines whether the Client is pre-registered.
 - X.509 certificates: If the Request Object contains an `x5c`, `x5t`, or `x5t#S256` header parameter, after validating the X.509 certificate chain, the Wallet MUST use the public key from the leaf-certificate of the X.509 certificate chain to verify the signature of the Request Object. In this case, the leaf-certificate MUST include a`dNSName` Subject Alternative Name (SAN) [RFC5280] or `uniformResourceIdentifier` SAN [RFC5280] that matches the `client_id`. If the Wallet can establish trust in the `client_id` authenticated through the certificate, e.g. because the `client_id` is contained in a list of trusted Client Identifiers, it MAY allow the Client to freely choose the `redirect_uri` or `response_uri` value. If not, the `redirect_uri` or `response_uri` value MUST match the `client_id` or FQDN of the `client_id`.
 - DID Resolution: If the `client_id` in the Request Object is a DID, the signature of the Request Object MUST be verified using a public key obtained from a `verificationMethod` property of a DID Document. Since a DID Document can include multiple public keys, the particular public key used to sign the request MUST be identified by the `kid` header parameter. To obtain the DID Document, the Wallet MUST use DID Resolution as defined by the DID method used by the Verifier. (Note that it is currently unspecified how to verify the `redirect_uri` or `response_uri` for DIDs.)
-- Verifier Attestation: If the Request Object contains a Verifier Attestation JWT as defined in (#verifier_attestation_jwt), the Wallet MUST verify the signature of the Request Object using the public key in the `cnf` claim in the Verifier Attestation JWT. This serves as proof of possesion of this key. Additionally, the `client_id` MUST equal the `sub` claim value in the Verifier Attestation JWT. The Wallet MUST validate the signature on the Verifier Attestation JWT. The `iss` claim value of the Verifier Attestation JWT MUST identify a party the Wallet trusts for issuing Verifier Attestation JWTs. If the issuer of the Verifier Attestation JWT includes a `redirect_uris` claim in the Verifier Attestation, the Wallet MUST ensure the `redirect_uri` or `response_uri` request parameter value exactly matches one of the `redirect_uris` array values.
+- Verifier Attestation: If the Request Object contains a Verifier Attestation JWT, as defined in (#verifier_attestation_jwt), the Wallet MUST verify the signature of the Request Object using the public key in the `cnf` claim in the Verifier Attestation JWT. This serves as proof of possession of this key. Additionally, the `client_id` MUST equal the `sub` claim value in the Verifier Attestation JWT. The Wallet MUST validate the signature on the Verifier Attestation JWT. The `iss` claim value of the Verifier Attestation JWT MUST identify a party the Wallet trusts for issuing Verifier Attestation JWTs. If the issuer of the Verifier Attestation JWT includes a `redirect_uris` claim in the Verifier Attestation, the Wallet MUST verify that the `redirect_uri` or `response_uri` request parameter value exactly matches one of the `redirect_uris` array values.
 - OpenID Federation: If the `client_id` in the Request Object is an Entity Identifier as defined in OpenID Federation [@!OpenID.Federation], the processing rules specified in OpenID Federation MUST be followed. When this is the case, the Entity Configuration for the Client is obtained at the path `<client_id>/.well-known/openid-federation`. Automatic Registration as defined in OpenID Federation MUST be used. The Authorization Request MAY also contain a `trust_chain` parameter, which can optimize the process of obtaining metadata. The `jwks` parameter of the resolved Verifier metadata obtained from the Trust Chain after applying the policies, according to OpenID Federation, MUST be used to verify the signature of the Request Object. The Wallet MUST verify the `redirect_uri` or `response_uri` request parameter matches one of the entries of the `redirect_uris` parameter of the resolved metadata.
 
 It is a Wallet-policy decision which method to choose to authenticate the Request Object and whether to accept unsigned Authorization Requests.