Embedded Disclosure Policy

An embedded disclosure policy lets issuers specify which relying parties a holder is permitted to disclose a credential to. It is embedded directly in a credential schema and transmitted to the wallet as part of credential metadata.

When a verifier requests disclosure, the wallet reads the policy and warns the user if the request comes from a party not covered by it. This gives holders visibility into whether a disclosure request is expected and authorized, and helps protect against phishing attacks where a malicious verifier impersonates a legitimate service.

This feature is defined in ETSI TS 119 472-3, and is designed to complement trust list infrastructure: where wallets subscribe to trust lists to evaluate verifiers, an embedded disclosure policy gives issuers a direct channel to communicate their own disclosure expectations.

The embeddedDisclosurePolicy field is optional in the Create Credential Schema request body.

Policy types

Three policy types are available:

policy value	Behavior
none	No restriction. The credential may be disclosed to any relying party.
allowList	Disclosure is permitted only to the relying parties named in options.values. Each entry is either a specific relying party identified by DN, or an ETSI entitlement URI covering a category of service providers.
rootOfTrust	Disclosure is permitted to any relying party whose certificate was issued under the specified CA, identified by the CA's DN and serial number together.

Examples

The examples below each create a minimal credential schema with one claim. The claims and formats blocks are the same in every case — what changes is the embeddedDisclosurePolicy.

No disclosure policy

Omitting embeddedDisclosurePolicy entirely is valid. You can also explicitly declare that a credential has no restrictions by setting policy to none:

{
    "layoutType": "CARD",
    "name": "docs_disclosure_none",
    "embeddedDisclosurePolicy": {
        "description": "This credential has no disclosure restrictions.",
        "policy": "none",
        "url": "https://example.com/policies/none"
    },
    "claims": [
        {
            "array": false,
            "datatype": "STRING",
            "key": "name",
            "mappings": [
                {
                    "format": "SD_JWT_VC",
                    "technicalKey": "name"
                }
            ],
            "required": true
        }
    ],
    "formats": [
        {
            "format": "SD_JWT_VC"
        }
    ]
}

Allow list

Use allowList to name specific relying parties. Each entry in options.values is either a dn or an entitlement:

• dn — identifies a specific relying party by their X.509 Distinguished Name in RFC 2253 (LDAPv3) format. A full DN pins an exact organization; a partial DN (fewer attributes) matches any certificate that contains those attributes.
• entitlement — a URI defined by ETSI that identifies a broad category of service providers rather than a specific party. Use this when you want to permit disclosure to any verifier that holds a recognized role within the ETSI trust framework.

{
    "layoutType": "CARD",
    "name": "docs_disclosure_list",
    "embeddedDisclosurePolicy": {
        "description": "Permitted relying parties for this credential.",
        "policy": "allowList",
        "url": "https://example.com/policies/allowlist",
        "options": {
            "values": [
                {
                    "dn": "CN=Kantonspolizei Zürich Verifier,O=Kantonspolizei Zürich,L=Zürich,ST=Zürich,C=CH"
                },
                {
                    "dn": "O=Swiss Federal Railways,C=CH"
                },
                {
                    "entitlement": "https://uri.etsi.org/19475/Entitlement/Service_Provider"
                }
            ]
        }
    },
    // claims and formats identical to the example above
}

The first entry matches a single, fully-identified verifier. The second matches any certificate issued to Swiss Federal Railways, regardless of the specific CN. The third permits disclosure to any relying party holding the ETSI Service Provider entitlement.

Root of trust

Use rootOfTrust to permit disclosure to any relying party whose certificate was issued by a specific CA, without needing to list individual parties. This is the more scalable option for production deployments, where a trusted national or organizational CA is already authorizing verifiers.

Each entry in options.values must include both dn and serial, together identifying the exact CA certificate:

{
    "layoutType": "CARD",
    "name": "docs_disclosure_root",
    "embeddedDisclosurePolicy": {
        "description": "Any relying party certified under the Swiss Government PKI root.",
        "policy": "rootOfTrust",
        "url": "https://example.com/policies/root-of-trust",
        "options": {
            "values": [
                {
                    "dn": "CN=Swiss Government Root CA III,O=Swiss Federal Chancellery,C=CH", // subject DN of the CA
                    "serial": "4A:1B:9C:2D:E3:F4:05:6B:7A:8C:9D:0E:1F:2A:3B:4C"
                }
            ]
        }
    },
    // claims and formats identical to the example above
}

The dn (subject DN of the CA) and serial together identify one specific CA certificate. Use the subject DN as it appears in the CA's own certificate, not the issuer DN from a relying party certificate. The wallet permits disclosure to any relying party whose certificate chains up to that CA.