From 82a0b00f06dc42c79d16b496bf74d7f38a3b6b88 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Fri, 10 Jan 2025 14:03:06 +0100 Subject: [PATCH 1/4] fix: add more explicit extension point for DIDs --- draft-ietf-oauth-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-sd-jwt-vc.md b/draft-ietf-oauth-sd-jwt-vc.md index 02d9ff8..988dc5d 100644 --- a/draft-ietf-oauth-sd-jwt-vc.md +++ b/draft-ietf-oauth-sd-jwt-vc.md @@ -346,7 +346,7 @@ obtain the public key using JWT VC Issuer Metadata as defined in (#jwt-vc-issuer 2. ensure that the `iss` value matches a `uniformResourceIdentifier` SAN entry of the end-entity certificate or that the domain name in the `iss` value matches the `dNSName` SAN entry of the end-entity 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. +Separate specifications or ecosystem regulations MAY define rules complementing or extending the rules defined above; however, such rules are beyond the scope of this specification. For example, an ecosystem MAY choose to define a profile that uses DIDs [@W3C.DID] for issuer key resolution by specifying encoding, resolution, and validation rules. See (#ecosystem-verification-rules) for security considerations applicable to these complementary or extended rules. If a recipient cannot validate that the public verification key corresponds to the `iss` value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. From 87cd8eb43a158c62d37ff3765e592dd688c6b09c Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Fri, 10 Jan 2025 14:05:59 +0100 Subject: [PATCH 2/4] fix: removed DID as an example --- draft-ietf-oauth-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-sd-jwt-vc.md b/draft-ietf-oauth-sd-jwt-vc.md index 988dc5d..8d323a0 100644 --- a/draft-ietf-oauth-sd-jwt-vc.md +++ b/draft-ietf-oauth-sd-jwt-vc.md @@ -346,7 +346,7 @@ obtain the public key using JWT VC Issuer Metadata as defined in (#jwt-vc-issuer 2. ensure that the `iss` value matches a `uniformResourceIdentifier` SAN entry of the end-entity certificate or that the domain name in the `iss` value matches the `dNSName` SAN entry of the end-entity 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 or extending the rules defined above; however, such rules are beyond the scope of this specification. For example, an ecosystem MAY choose to define a profile that uses DIDs [@W3C.DID] for issuer key resolution by specifying encoding, resolution, and validation rules. See (#ecosystem-verification-rules) for security considerations applicable to these complementary or extended rules. +Separate specifications or ecosystem regulations MAY define rules complementing or extending the rules defined above; however, such rules are beyond the scope of this specification. For example, an ecosystem MAY choose to define a profile that specifies additional encoding, resolution, and validation rules. See (#ecosystem-verification-rules) for security considerations applicable to these complementary or extended rules. If a recipient cannot validate that the public verification key corresponds to the `iss` value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. From 143dd009a8597a777cd5dd182a5d14e28f0c8918 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Fri, 10 Jan 2025 14:07:07 +0100 Subject: [PATCH 3/4] fix: add doc history --- draft-ietf-oauth-sd-jwt-vc.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-oauth-sd-jwt-vc.md b/draft-ietf-oauth-sd-jwt-vc.md index 8d323a0..84da016 100644 --- a/draft-ietf-oauth-sd-jwt-vc.md +++ b/draft-ietf-oauth-sd-jwt-vc.md @@ -1570,6 +1570,10 @@ for their contributions (some of which substantial) to this draft and to the ini # Document History +-10 + +* Make extension point for issuer key resolution more explicit + -09 * Use SD-JWT KB in place of SD-JWT with Key Binding JWT From 5b96ff5a257cc7179e8370239598d5ad24e0f8cf Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Mon, 13 Jan 2025 16:14:33 +0100 Subject: [PATCH 4/4] Applied Daniel's suggestion Co-authored-by: Daniel Fett --- draft-ietf-oauth-sd-jwt-vc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-sd-jwt-vc.md b/draft-ietf-oauth-sd-jwt-vc.md index 84da016..664bab5 100644 --- a/draft-ietf-oauth-sd-jwt-vc.md +++ b/draft-ietf-oauth-sd-jwt-vc.md @@ -346,7 +346,7 @@ obtain the public key using JWT VC Issuer Metadata as defined in (#jwt-vc-issuer 2. ensure that the `iss` value matches a `uniformResourceIdentifier` SAN entry of the end-entity certificate or that the domain name in the `iss` value matches the `dNSName` SAN entry of the end-entity 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 or extending the rules defined above; however, such rules are beyond the scope of this specification. For example, an ecosystem MAY choose to define a profile that specifies additional encoding, resolution, and validation rules. See (#ecosystem-verification-rules) for security considerations applicable to these complementary or extended rules. +To enable additional methods for Issuer verification key resolution, separate specifications or ecosystem regulations MAY define rules complementing or extending the rules defined above; however, such rules are beyond the scope of this specification. For example, an ecosystem MAY choose to define a profile that specifies additional encoding, resolution, and validation rules. See (#ecosystem-verification-rules) for security considerations applicable to these complementary or extended rules. If a recipient cannot validate that the public verification key corresponds to the `iss` value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected.