Fixed obtaining verification key rules (#183)

* fix: fixed obtaining verification key rules

* fix: added entry to change log

* fix: added more explicit language to x509 rule

* Fixed typo

* fix: renamed obtaining public key for issuer-signed jwts section to Issuer-signed JWT verification key validation; fixing #185

* new line in history

* fix: added back removed line to reject VCs where the key cannot be validated

* fix: reconciled changes with PR #190

---------

Co-authored-by: Oliver Terbu <[email protected]>
Co-authored-by: Oliver Terbu <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>

draft-ietf-oauth-sd-jwt-vc.md

@@ -306,8 +306,8 @@ If Key Binding is required (refer to the security considerations in Section 11.6
 according to Section 8 of [@!I-D.ietf-oauth-selective-disclosure-jwt]. To verify
 the Key Binding JWT, the `cnf` claim of the SD-JWT MUST be used.
 
-Furthermore, the recipient of the SD-JWT VC MUST obtain the public verification key
-for the Issuer-signed JWT as defined in (#public-key-discovery-for-issuer-signed-jwts).
+Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key
+for the Issuer-signed JWT as defined in (#issuer-signed-jwt-verification-key-validation).
 
 If there are no selectively disclosable claims, there is no need to process the
 `_sd` claim nor any Disclosures.
@@ -321,18 +321,18 @@ Any claims used that are not understood MUST be ignored.
 Additional validation rules MAY apply, but their use is out of the scope of this
 specification.
 
-## Obtaining Public Key for Issuer-signed JWTs {#public-key-discovery-for-issuer-signed-jwts}
+## Issuer-signed JWT Verification Key Validation {#issuer-signed-jwt-verification-key-validation}
 
 A recipient of an SD-JWT VC MUST apply the following rules to validate that the public
 verification key for the Issuer-signed JWT corresponds to the `iss` value:
 
 - JWT Issuer Metadata: If a recipient supports JWT Issuer Metadata and if the `iss` value contains an HTTPS URI, the recipient MUST
 obtain the public key using JWT Issuer Metadata as defined in (#jwt-issuer-metadata).
-- DID Document Resolution: If a recipient supports DID Document Resolution and if the `iss` value contains a DID [@W3C.DID], the recipient MUST retrieve the public key from the DID Document resolved from the DID in the `iss` value. In this case, if the `kid` JWT header parameter is present, the `kid` MUST be a relative or absolute DID URL of the DID in the `iss` value, identifying the public key.
-- X.509 Certificates: If the recipient supports X.509 Certificates, the recipient MUST obtain the public key from the leaf X.509 certificate defined by the `x5c`, `x5c`, or `x5t` JWT header parameters of the Issuer-signed JWT and validate the X.509
+- X.509 Certificates: If the recipient supports X.509 Certificates, the recipient MUST obtain the public key from the leaf X.509 certificate defined by the `x5c` JWT header parameters of the Issuer-signed JWT and validate the X.509
 certificate chain in the following cases:
-    - If the `iss` value contains a DNS name encoded as a URI using the DNS URI scheme [@RFC4501]. In this case, the DNS name MUST match a `dNSName` Subject Alternative Name (SAN) [@RFC5280] entry of the leaf certificate.
-    - If the `iss` value contains a URN using the URN URI scheme [@RFC2141]. In this case, the URN MUST match a `unifiedResourceName` SAN entry of the leaf certificate.
+    - If the `iss` value contains a DNS name encoded as a URI using the DNS URI scheme [@RFC4501], the DNS name MUST match a `dNSName` Subject Alternative Name (SAN) [@RFC5280] entry of the leaf certificate.
+    - In all other cases, the `iss` value MUST match a `uniformResourceIdentifier` SAN entry of the leaf certificate.
+- DID Document Resolution: If a recipient supports DID Document Resolution and if the `iss` value contains a DID [@W3C.DID], the recipient MUST retrieve the public key from the DID Document resolved from the DID in the `iss` value. In this case, if the `kid` JWT header parameter is present, the `kid` MUST be a relative or absolute DID URL of the DID in the `iss` value, identifying the public key.
 
 Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification. See (#ecosystem-verification-rules) for security considerations.
 
@@ -509,7 +509,7 @@ Additional considerations can be found in [@OWASP_SSRF].
 ## Ecosystem-specific Public Key Verification Methods {#ecosystem-verification-rules}
 
 When defining ecosystem-specific rules for the verification of the public key,
-as outlined in (#public-key-discovery-for-issuer-signed-jwts), it is critical
+as outlined in (#issuer-signed-jwt-verification-key-validation), it is critical
 that those rules maintain the integrity of the relationship between the `iss` value
 within the Issuer-signed JWT and the public keys of the Issuer.
 
@@ -678,8 +678,9 @@ for their contributions (some of which substantial) to this draft and to the ini
 # Document History
 
 -02
-
 * Made specific rules for public verification key validation conditional
+* Finetuned rules for obtaining public verification key
+* Editorial changes
 
 -01