WARNING
This specification is outdatet and has been archived.
This document defines a set of requirements based on new or existing technical specifications and aims to enable interoperability between issuers, wallets and verifiers of credentials in the swiyu Public Beta Trust Infrastructure. It is intended as an interoperability profile that can be used by implementers. As such it shows how the referenced specifications can, and sometimes have to be, implemented.
The target audience of the document are early adopters who want to use the swiyu Public Beta Trust Infrastructure to:
The following specifications are in scope of this “Swiss Profile”:
The following assumptions apply:
The following items are currently out of scope but might be added in future versions:
The following table defines which specification must be supported by an actor (issuer, verifier, wallet) in order to comply with this profile.
| Specification | Issuer | Wallet | Verifier |
|---|---|---|---|
| OID4VP | MAY | MUST | MUST |
| OID4VCI | MUST | MUST | MAY |
| DID:TDW/DID:WEBVH | MUST | MUST | MUST |
| SD-JWT VC profile | MUST | MUST | MUST |
| Status List | MUST | MUST | MUST |
| Trust Protocol | MAY | MUST | MAY |
Issuers and verifiers use DID:TDW version 0.3 as identifiers.
Implementations of this profile:
portable to false in the first DID log entry.method to did:tdw:0.3 in the first DID log entry.The following specification defines the requirements of the to DID Document.
| Property | Description |
|---|---|
| @context | MUST contain https://www.w3.org/ns/did/v1 and https://w3id.org/security/jwk/v1 |
| id | MUST contain the DID of the DID document |
| verificationMethod | MUST contain at least one public key from type PublicKeyJwk |
| alsoKnownAS | MUST NOT be used |
| controller | MUST NOT be used |
| service | MUST NOT be used |
Issuer and Verifier have the possibility to add metatada to their DIDs with:
Implementations of this profile:
This chapter maps to OpenID4VCI draft 13
urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be supported as defined in Section 4.1.1 in OpenID4VCI.openid-credential-offer:// MUST be supported.Both sending credential offer same-device and cross-device are supported.
credential_issuer MAY be defineddisplay MAY contain the following objects
name MAY be the self-attested name of the issuerlogo MAY contain the self-attested logo of the issuer.
uri MUST be a DATA URL with mime-type image/png or image/jpgalt_text MAY be a text that describes the logolocale MAY be the locale of the self-attested issuer metadatacredential_configurations_supported MUST contain
format MUST be vc+sd-jwtcryptographic_binding_methods_supported MUST be jwkcredential_signing_alg_values_supported MUST be
ES256proof_types_supported MAY be defined
jwt.proof_signing_alg_values_supported MUST contain at least ES256display MAY be defined, and when defined MUST at least contain one of the following object
name MUST be the self-attested name of the credentiallogo MAY contain the self-attested logo of the credential.
uri MUST be a DATA URL with mime-type image/png or image/jpgalt_text MAY be a text that describes the logolocale MAY be the locale of the self-attested credetial metadatadescription MAY be definedbackground_color MAY be definedformat MUST be vc+sd-jwtproof MAY be defined, and when defined MUST contain:
proof_type MUST be jwtThe JOSE header MUST contain following values:
alg MUST be ES256kid MUST be JWK encoded as a DID:JWKThe JWT body MUST contain following values:
nonce MUST be defined, if cryptographic device binding is requested.credential MUST be definedIf the wallet was sending a signed nonce on their proof, the following value MUST be added:
c_nonce MUST be definedgrant_type MUST be urn:ietf:params:oauth:grant-type:pre-authorized_codec_nonce MUST be defined, if cryptographic device binding is requested.This chapter maps to OpenID4VP draft 20
response_type MUST be vp_token.response_mode MUST be direct_postresponse_uri MUST be definedclient_id MAY be set if Verifier authentication is requested.client_id_scheme, if used with a DID, MUST be did.client_metadata MAY contain
client_name MAY be definedlogo_uri MAY be defined but MUST be a data URL.nonce MUST be defined, if cryptographic device binding is requested.presentation_definition MUST be definedpresentation_definition MUST contain
id MUST be definedinput_descriptors MUST contain at least one object with:
id MUST be definedname MAY be definedpurpose MAY be definedformat MAY be defined, when defined MUST be vc+sd-jwt.constraints MAY be defined, when defined MUST contain object fields with the following properties
path MUST be definedfilter MAY be defined to be used with the vct claim from the SD-JWT VC profilevp_token MUST be definedpresentation_submission MUST be defined.presentation_submission MUST contain:
id MUST be defineddefinition_id MUST be defineddescriptor_map MUST be defined and MUST contain:
id MUST be definedformat MUST be vc+sd-jwtpath MUST be definedAs credential format, SD-JWT VCs as defined in ietf-oauth-sd-jwt-vc MUST be supported.
In addition, this profile defines the following additional requirements.
Compact serialization MUST be supported as defined in ietf-oauth-selective-disclosure-jwt. The following JWT Claims MUST be supported content
| Claim | SD-JWT |
|---|---|
| vct | MUST |
| iss | MUST |
| iat | SHOULD |
| exp | SHOULD |
| status | SHOULD |
| sub | MAY |
| cnf | MAY |
exp, iat claims and/or a status claim to express the validity period of an SD-JWT-VC. The wallet and the verifier MUST support those mechanisms.vct claim MUST be defined and is treated as an unresolvable string.iss claim MUST be a DID. The iss value is used to obtain Issuer’s signing key as defined in section Issuer identification and key resolution.sub claim MAY be used, if there is a requirement to provide the subject’s identifier assigned and maintained by the issuer.cnf claim [RFC7800] MUST conform to the definition given in Device Binding Chapter.kid parameter.WARNING Issuers can issue low assurance VCs without device binding but they can become vulnerable to replay attacks.
This section specifies how SD-JWT VCs as defined in I-D.ietf-oauth-sd-jwt-vc are used in conjunction with the OpenID4VC specifications.
The credential format identifier is vc+sd-jwt. This format identifier is used in issuance and presentation requests.
The following additional credential issuer metadata are defined for this credential format to be used in addition to those defined in Section 10.2 of OpenID4VCI.
credential_configuations_supported MUST contain
vct MUST be defined.claims MAY contain objects with the following properties
value_type MAY be defineddisplay MAY be defined for each credential claim
name MAY be the localized credential claim namelocale MAY be the credential claim name localeorder MAY be an array with the credential claim in the order of displayAn issuer MAY at their discretion add a status entry to their verifiable credential.
The credential status specification to use depends on the credential format as follow:
| Credential format | Specification |
|---|---|
| SD-JWT VC | Token Status List JSON format only |
kid from the JOSE header MUST be an absolute did:tdw with a key reference.iss and sub from the JWT body MUST be a did:tdw.TrustStatementMetadataV1 MUST be supported.This chapter maps to Trust Protocol based on VCs V0.1
Issuers, wallets and verifiers MUST support P-256 (secp256r1) as a key type with ES256 JWT algorithm for signing and signature validation whenever this profiles requires to do so.
SHA256 MUST be supported by all the entities as the hash algorithm to generate and validate digests.
NOTE
When using this profile with other cryptosuites, it is recommended to be explicit about which entity is required to support which curve for signing and/or signature validation
In the current profile, sections SD-JWT VC, credential status and device binding contain no protection against user correlation. To adress this batch-issuance will be implemented in a future release.