Internet-Draft | SD-JWT VC | August 2023 |
Terbu & Fett | Expires 17 February 2024 | [Page] |
- Workgroup:
- Web Authorization Protocol
- Internet-Draft:
- draft-ietf-oauth-sd-jwt-vc-00
- Published:
- Intended Status:
- Standards Track
- Expires:
SD-JWT-based Verifiable Credentials (SD-JWT VC)
Abstract
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] format. It can be used without any selective disclosable claims, too.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 February 2024.¶
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
1.1. Issuer-Holder-Verifier Model
In the so-called Issuer-Holder-Verifier Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers. Verifiable Credentials are cryptographically signed statements about a Subject, typically the Holder.¶
Verifiers can check the authenticity of the data in the Verifiable Credentials and optionally enforce Key Binding, i.e., ask the Holder to prove that they are the intended holder of the Verifiable Credential, for example, by proving possession of a cryptographic key referenced in the credential. This process is further described in [I-D.ietf-oauth-selective-disclosure-jwt].¶
To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider. The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer.¶
This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set. It can be used when there are no selective disclosable claims, too.¶
1.2. Rationale
JSON Web Tokens (JWTs) [RFC7519] can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.¶
Selective Disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).¶
SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures. However, SD-JWT itself does not define the claims that must be used within the payload or their semantics.¶
This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload. Those Verifiable Credentials are called SD-JWT VCs.¶
SD-JWTs VC can contain claims that are registered in "JSON Web Token Claims" registry as defined in [RFC7519], as well as public and private claims.¶
Note: This specification does not utilize the W3C's Verifiable Credentials Data Model v1.0, v1.1, or v2.0.¶
1.3. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
1.4. Terms and Definitions
This specification uses the terms "Holder", "Issuer", "Verifier", "Key Binding JWT" defined by [I-D.ietf-oauth-selective-disclosure-jwt].¶
- Verifiable Credential (VC):
- An Issuer-signed assertion with claims about a Subject.¶
- SD-JWT-based Verifiable Credential (SD-JWT VC):
- A Verifiable Credential encoded using the format defined in [I-D.ietf-oauth-selective-disclosure-jwt]. It may or may not contain selectively disclosable claims.¶
- Unsecured Payload of an SD-JWT VC:
- A JSON object containing all selectively disclosable and non-selectively disclosable claims of the SD-JWT VC. The Unsecured Payload acts as the input JSON object to issue an SD-JWT VC complying to this specification.¶
- Status Provider:
- An entity that provides status information (e.g. revocation) about a Verifiable Credential.¶
3. Use Cases
TBD: explain use cases of the Issuer-Holder-Verifier Model.¶
TBD: conventional crypt, hardware security, hsm, mobile secure area, compliance with FIPS¶
4. Verifiable Credentials based on SD-JWT
This section defines encoding, validation and processing rules for SD-JWT VCs.¶
4.1. Media Type
SD-JWT VCs compliant with this specification MUST use the media type
application/vc+sd-jwt
as defined in Appendix A.2.1.¶
4.2. Data Format
SD-JWT VCs MUST be encoded using the SD-JWT format defined in Section 5 of [I-D.ietf-oauth-selective-disclosure-jwt]. A presentation of an SD-JWT VC MAY contain a Key Binding JWT.¶
Note that in some cases, an SD-JWT VC MAY have no selectively disclosable claims, and therefore the encoded SD-JWT will not contain any Disclosures.¶
4.2.1. Header Parameters
This section defines JWT header parameters for the SD-JWT component of the SD-JWT VC.¶
The typ
header parameter of the SD-JWT MUST be present. The typ
value MUST
use vc+sd-jwt
. This indicates that the payload of the SD-JWT contains plain
JSON and follows the rules as defined in this specification. It further
indicates that the SD-JWT is a SD-JWT component of a SD-JWT VC.¶
The following is a non-normative example of a decoded SD-JWT header:¶
{ "alg": "ES256", "typ": "vc+sd-jwt" }¶
4.2.2. Claims
This section defines the claims that can be included in the payload of SD-JWT VCs.¶
4.2.2.1. type
claim
This specification defines the JWT claim type
. The type
value
MUST be a case-sensitive StringOrURI
value serving as an identifier
for the type of the SD-JWT VC. A type defines which claims may or must appear in the
Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be
selectively disclosable. This specification does not define any type
values; instead
it is expected that ecosystems using SD-JWT VCs define such values including
the semantics of the respective claims and associated rules (e.g., policies for issuing and
validating credentials beyond what is defined in this specification).¶
The following is a non-normative example of how type
is used to express
a type:¶
{ "type": "IdentityCredential" }¶
For example, a type IdentityCredential
can be defined such that at least the registered JWT claims given_name
, family_name
, birthdate
, and address
must appear in the Unsecured Payload. Additionally, the registered JWT claims email
and phone_number
, and the private claims is_over_18
, is_over_21
, and is_over_65
may be used. The type might also indicate that given_name
, family_name
, birthdate
, address
can be selectively disclosable.¶
4.2.2.2. Registered JWT Claims
SD-JWT VCs MAY use any claim registered in the "JSON Web Token Claims" registry as defined in [RFC7519].¶
If present, the following registered JWT claims MUST be included in the SD-JWT and MUST NOT be included in the Disclosures, i.e. cannot be selectively disclosed:¶
-
iss
¶ -
iat
¶ -
nbf
¶ -
exp
¶ -
cnf
¶- REQUIRED when Cryptographic Key Binding is to be supported. Contains the confirmation method as defined in [RFC7800]. It SHOULD contain a JWK as defined in Section 3.2 of [RFC7800]. For Cryptographic Key Binding, the Key Binding JWT in the Combined Format for Presentation MUST be signed by the key identified in this claim.¶
-
type
¶- REQUIRED. The type of the Verifiable Credential, e.g.,
IdentityCredential
, as defined in Section 4.2.2.1.¶
- REQUIRED. The type of the Verifiable Credential, e.g.,
-
status
¶- OPTIONAL. The information on how to read the status of the Verifiable Credential. See [I-D.looker-oauth-jwt-cwt-status-list] for more information.¶
The following registered JWT claims MAY be contained in the SD-JWT or in the Disclosures and MAY be selectively disclosed:¶
4.2.2.3. Public JWT claims
Additional public claims MAY be used in SD-JWT VCs depending on the application.¶
4.2.2.4. SD-JWT VC without Selectively Disclosable Claims
An SD-JWT VC MAY have no selectively disclosable claims.
In that case, the SD-JWT VC MUST NOT contain the _sd
claim in the JWT body. It also
MUST NOT have any Disclosures.¶
4.3. Example
The following is a non-normative example of an unsecured payload of an SD-JWT VC.¶
{ "type": "IdentityCredential", "given_name": "John", "family_name": "Doe", "email": "johndoe@example.com", "phone_number": "+1-202-555-0101", "address": { "street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US" }, "birthdate": "1940-01-01", "is_over_18": true, "is_over_21": true, "is_over_65": true }¶
The following is a non-normative example of how the unsecured payload of the SD-JWT VC above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable:¶
{ "_sd": [ "09vKrJMOlyTWM0sjpu_pdOBVBQ2M1y3KhpH515nXkpY", "2rsjGbaC0ky8mT0pJrPioWTq0_daw1sX76poUlgCwbI", "EkO8dhW0dHEJbvUHlE_VCeuC9uRELOieLZhh7XbUTtA", "IlDzIKeiZdDwpqpK6ZfbyphFvz5FgnWa-sN6wqQXCiw", "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE", "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo", "jdrTE8YcbY4EifugihiAe_BPekxJQZICeiUQwY9QqxI", "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4" ], "iss": "https://example.com/issuer", "iat": 1683000000, "exp": 1883000000, "type": "IdentityCredential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" } } }¶
Note that a cnf
claim has been added to the SD-JWT payload to express the
confirmation method of the Key Binding.¶
The following are the Disclosures belonging to the SD-JWT payload above:¶
Claim given_name
:¶
- SHA-256 Hash:
jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
¶ - Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
biJd
¶ - Contents:
["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]
¶
Claim family_name
:¶
- SHA-256 Hash:
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
¶ - Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
ZSJd
¶ - Contents:
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
¶
Claim email
:¶
- SHA-256 Hash:
JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
¶ - Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
ZXhhbXBsZS5jb20iXQ
¶ - Contents:
["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]
¶
Claim phone_number
:¶
- SHA-256 Hash:
PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
¶ - Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
MS0yMDItNTU1LTAxMDEiXQ
¶ - Contents:
["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",
"+1-202-555-0101"]
¶
Claim address
:¶
- SHA-256 Hash:
IlDzIKeiZdDwpqpK6ZfbyphFvz5FgnWa-sN6wqQXCiw
¶ - Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVl
dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv
d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
¶ - Contents:
["Qg_O64zqAxe412a108iroA", "address", {"street_address":
"123 Main St", "locality": "Anytown", "region": "Anystate",
"country": "US"}]
¶
Claim birthdate
:¶
- SHA-256 Hash:
jdrTE8YcbY4EifugihiAe_BPekxJQZICeiUQwY9QqxI
¶ - Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImJpcnRoZGF0ZSIsICIxOTQw
LTAxLTAxIl0
¶ - Contents:
["AJx-095VPrpTtN4QMOqROA", "birthdate", "1940-01-01"]
¶
Claim is_over_18
:¶
- SHA-256 Hash:
09vKrJMOlyTWM0sjpu_pdOBVBQ2M1y3KhpH515nXkpY
¶ - Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImlzX292ZXJfMTgiLCB0cnVl
XQ
¶ - Contents:
["Pc33JM2LchcU_lHggv_ufQ", "is_over_18", true]
¶
Claim is_over_21
:¶
- SHA-256 Hash:
2rsjGbaC0ky8mT0pJrPioWTq0_daw1sX76poUlgCwbI
¶ - Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImlzX292ZXJfMjEiLCB0cnVl
XQ
¶ - Contents:
["G02NSrQfjFXQ7Io09syajA", "is_over_21", true]
¶
Claim is_over_65
:¶
- SHA-256 Hash:
EkO8dhW0dHEJbvUHlE_VCeuC9uRELOieLZhh7XbUTtA
¶ - Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlzX292ZXJfNjUiLCB0cnVl
XQ
¶ - Contents:
["lklxF5jMYlGTPUovMNIvCA", "is_over_65", true]
¶
The SD-JWT and the Disclosures would then be serialized by the Issuer into the following format for issuance to the Holder:¶
eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY WxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiO iAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsc zd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2d DRqVDlGMkhaUSJ9fX0.eUqZ_0dIAWQoGxtGAwh4Dy_JreQgJF0S9aspLpgUdQM5GFIke 6YyNibeou-bLYeqpy5OA_M_0p_s0U0cFlMR7g~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STj l3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BI iwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwg ImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZ W5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNj R6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIj EyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueX N0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIi wgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdW ZRIiwgImlzX292ZXJfMTgiLCB0cnVlXQ~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiw gImlzX292ZXJfMjEiLCB0cnVlXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlz X292ZXJfNjUiLCB0cnVlXQ~¶
4.4. Verification and Processing
The recipient (Holder or Verifier) of an SD-JWT VC MUST process and verify an SD-JWT VC as described in Section 6 of [I-D.ietf-oauth-selective-disclosure-jwt].¶
If Key Binding is required (refer to the security considerations in Section 9.6 of [I-D.ietf-oauth-selective-disclosure-jwt]), the Verifier MUST verify the Key Binding JWT
according to Section 6 of [I-D.ietf-oauth-selective-disclosure-jwt]. To verify
the Key Binding JWT, the cnf
claim of the SD-JWT MUST be used.¶
For the verification, the iss
claim in the SD-JWT MAY be used to retrieve the
public key from the JWT Issuer Metadata configuration (as defined in
Section 5) of the SD-JWT VC issuer. Alternative methods MAY be used
to obtain the public key to verify the signature of the SD-JWT.¶
If there are no selectively disclosable claims, there is no need to process the
_sd
claim nor any Disclosures.¶
If status
is present in the verified payload of the SD-JWT, the status SHOULD
be checked. It depends on the Verifier policy to reject or accept a presentation
of a SD-JWT VC based on the status of the Verifiable Credential.¶
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.¶
5. JWT Issuer Metadata
This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer
Metadata configuration of the JWT Issuer of the JWT. The JWT Issuer is
identified by the iss
claim in the JWT. Use of the JWT Issuer Metadata
is OPTIONAL.¶
JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer Metadata
configuration available at the path formed by concatenating the string
/.well-known/jwt-issuer
to the iss
claim value in the JWT. The iss
MUST
be a case-sensitive URL using the HTTPS scheme that contains scheme, host and,
optionally, port number and path components, but no query or fragment
components.¶
5.1. JWT Issuer Metadata Request
A JWT Issuer Metadata configuration MUST be queried using an HTTP GET
request
at the path defined in Section 5.¶
The following is a non-normative example of a HTTP request for the JWT Issuer
Metadata configuration when iss
is set to https://example.com
:¶
GET /.well-known/jwt-issuer HTTP/1.1 Host: example.com¶
If the iss
value contains a path component, any terminating /
MUST be
removed before inserting /.well-known/
and the well-known URI suffix
between the host component and the path component.¶
The following is a non-normative example of a HTTP request for the JWT Issuer
Metadata configuration when iss
is set to https://example.com/user/1234
:¶
GET /.well-known/jwt-issuer/user/1234 HTTP/1.1 Host: example.com¶
5.2. JWT Issuer Metadata Response
A successful response MUST use the 200 OK HTTP
and return the JWT Issuer
Metadata configuration using the application/json
content type.¶
An error response uses the applicable HTTP status code value.¶
This specification defines the following JWT Issuer Metadata configuration parameters:¶
-
issuer
REQUIRED. The JWT Issuer identifier, which MUST be identical to theiss
value in the JWT.¶ -
jwks_uri
¶ -
jwks
¶
JWT Issuer Metadata MUST include either jwks_uri
or jwks
in their JWT
Issuer Metadata, but not both.¶
It is RECOMMENDED that the JWT contains a kid
JWT header parameter that can
be used to lookup the public key in the JWK Set included by value or referenced
in the JWT Issuer Metadata.¶
The following is a non-normative example of a JWT Issuer Metadata configuration
including jwks
:¶
{ "issuer":"https://example.com", "jwks":{ "keys":[ { "kid":"doc-signer-05-25-2022", "e":"AQAB", "n":"nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe 2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ", "kty":"RSA" } ] } }¶
The following is a non-normative example of a JWT Issuer Metadata
configuration including jwks_uri
:¶
{ "issuer":"https://example.com", "jwks_uri":"https://jwt-issuer.example.org/my_public_keys.jwks" }¶
Additional JWT Issuer Metadata configuration parameters MAY also be used.¶
5.3. JWT Issuer Metadata Validation
The issuer
value returned MUST be identical to the iss
value of the JWT. If
these values are not identical, the data contained in the response MUST NOT be
used.¶
6. Presenting Verifiable Credentials
This section defines encoding, validation and processing rules for presentations of SD-JWT VCs.¶
6.1. Key Binding JWT
If the presentation of the SD-JWT VC includes a Key Binding JWT, the following claims are used within the Key Binding JWT:¶
-
nonce
¶- REQUIRED. String value used to associate a transaction between a Verifier
an a Holder, and to mitigate replay attacks. The value is passed
through unmodified from the Verifier to the Key Binding JWT. Sufficient
entropy MUST be present in the
nonce
values used to prevent attackers from guessing values.¶
- REQUIRED. String value used to associate a transaction between a Verifier
an a Holder, and to mitigate replay attacks. The value is passed
through unmodified from the Verifier to the Key Binding JWT. Sufficient
entropy MUST be present in the
-
aud
¶ -
iat
¶ -
exp
¶
The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored.¶
6.2. Examples
The following is a non-normative example of a presentation of the SD-JWT shown above including a Key Binding JWT:¶
eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY WxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiO iAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsc zd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2d DRqVDlGMkhaUSJ9fX0.eUqZ_0dIAWQoGxtGAwh4Dy_JreQgJF0S9aspLpgUdQM5GFIke 6YyNibeou-bLYeqpy5OA_M_0p_s0U0cFlMR7g~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm 9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgIm xvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cn kiOiAiVVMifV0~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZ SI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL2V4YW1wbGUuY29tL3Zlcmlma WVyIiwgImlhdCI6IDE2OTIxODk2Nzd9.GikUOdFdJwdSQEnpbrW1gapU4xKq6e1zPlSQ BvudxBqxea-sNVAqYjOyaDjcwUFFPsZoDoR4Vi9i0VMk8rgqeg¶
In this presentation, the Holder provides only the Disclosure for the claim
address
. Other claims are not disclosed to the Verifier.¶
The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:¶
eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY WxnIjogInNoYS0yNTYifQ.-qHdV-T4fTH8bez7DFORjWcr3Bs5diCMIEGAOt__PYMc20 H_678SHcRHzjEcH6f2MZsIxBJy7yesYsbGg7oq5w~WyJRZ19PNjR6cUF4ZTQxMmExMDh pcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0Iiw gImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW5 0cnkiOiAiVVMifV0~¶
7. Security Considerations
TBD: Verifier provided nonce
.¶
8. Privacy Considerations
TBD: Holder provided nonce via jti
.¶
10. Normative References
- [I-D.ietf-oauth-selective-disclosure-jwt]
- Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05>.
- [I-D.looker-oauth-jwt-cwt-status-list]
- Looker, T. and P. Bastian, "JWT and CWT Status List", Work in Progress, Internet-Draft, draft-looker-oauth-jwt-cwt-status-list-01, , <https://datatracker.ietf.org/doc/html/draft-looker-oauth-jwt-cwt-status-list-01>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC7519]
- Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
- [RFC7800]
- Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/info/rfc7800>.
11. Informative References
- [RFC7517]
- Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/info/rfc7517>.
Appendix A. IANA Considerations
A.1. JSON Web Token Claims Registration
-
Claim Name: "type"¶
- Claim Description: Credential Type¶
- Change Controller: IESG¶
- Specification Document(s): Section 4.2.2.1 of this document¶
A.2. Media Types Registry
A.2.1. application/vc+sd-jwt
The Internet media type for a SD-JWT VC is application/vc+sd-jwt
.¶
Type name: : application
¶
Subtype name: : vc+sd-jwt
¶
Required parameters: : n/a¶
Optional parameters: : n/a¶
Encoding considerations: : 8-bit code points; SD-JWT VC values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~') characters.¶
Security considerations: : See Security Considerations in Section 7.¶
Interoperability considerations: : n/a¶
Appendix B. Acknowledgements
We would like to thank Alen Horvat, Andres Uribe, Brian Campbell, Christian Bormann, Giuseppe De Marco, Michael Jones, Mike Prorock, Orie Steele, Paul Bastian, Torsten Lodderstedt, Tobias Looker, and Kristina Yasuda for their contributions (some of which substantial) to this draft and to the initial set of implementations.¶
Appendix C. Document History
-00¶
- Upload as draft-ietf-oauth-sd-jwt-vc-00¶
- Aligned terminology and descriptions with latest version of SD-JWT¶
[[ pre Working Group Adoption: ]]¶
-00¶