Swiss Profile Issuance V1.0

Status: Draft
Published:
Effective:
Affected Components:
Internal Reference: EIDARTFE-1526

Payload Encryption, Signed Metadata, and DPoP were previously introduced as optional security features and are now moving from “migrate” to “enforce”. These features only provide their intended security benefit once they are actually enforced across the ecosystem rather than merely supported. This change closes the remaining security enforcement gaps against swiss-profile-issuance 1.0: the Credential Issuer will require DPoP, encrypted credential requests/responses (including deferred flows), and signed, trusted Metadata; Wallets must correspondingly establish trust in Metadata signers and reject non-compliant responses.

Action required

DID Resolver

Tag ⚠️ Required soon Tag 🚨 Breaking Tag 🆕 Optional Tag ✅ Improvement Tag 🐞 Fix

Generic Issuer

🚨 Nonce Response: the response MUST be made uncacheable by including a Cache-Control: no-store header.
🚨 Credential Request: enforce the DPoP header (planned to take effect once Wallets have implemented DPoP support).
🚨 Enforce credential_response_encryption on Credential Responses.
🚨 Enforce credential_request_encryption on Credential Requests (planned to take effect once Wallets have implemented request encryption).
🚨 Enforce correct usage of credential_configuration_id.
🚨 Deferred Credential Endpoint: enforce the DPoP header (planned to take effect once Wallets have implemented DPoP support).
🚨 Enforce Payload Encryption on Deferred Credential Requests, and require that Deferred Credential Responses are encrypted as well.
🚨 Reject any message that is unencrypted when encryption was required (applies to both requests and responses).
🚨 Enforce Signed Metadata for the Credential Issuer Metadata.
🚨 Enforce presence of the following Credential Issuer Metadata parameters: $.nonce_endpoint, $.credential_request_encryption, $.credential_response_encryption.

Generic Verifier

–

Wallet

🚨 When requesting signed Metadata, establish trust in the signer of that Metadata (via the applicable trust protocol); reject the signed Metadata if trust cannot be established.
🚨 Enforce presence of the required Credential Issuer Metadata parameters ($.nonce_endpoint, $.credential_request_encryption, $.credential_response_encryption) when reading issuer Metadata.
⚠️ Implement DPoP support, Credential Request encryption, and Deferred Credential Request/Response encryption ahead of the corresponding enforcement taking effect at the Issuer.

Status Registry

–

Migration steps

  1. Wallets implement DPoP, Credential Request encryption, and Deferred Credential Request/Response encryption.
  2. Wallets implement Metadata signature verification and trust establishment for the Metadata signer.
  3. Issuers enforce Signed Metadata, required Metadata parameters, and correct credential_configuration_id usage.
  4. Issuers enforce DPoP and Payload Encryption (Credential Request/Response and Deferred Credential Request/Response), rejecting unencrypted messages where encryption is required.
  5. Issuers make Nonce Endpoint responses uncacheable (Cache-Control: no-store).

Timeline

{DATE} {Wallet-side support (DPoP, encryption, Metadata trust) complete}
{DATE} {Issuer-side enforcement effective}