Your organization is ready to implement verifiable credentials, and you need a governance framework that balances innovation with compliance. The Better Identity Coalition is circulating a draft voluntary code of conduct for verifiable credentials, signaling the industry's recognition of the need for practical guardrails. However, voluntary guidelines only work if you translate them into enforceable policy.
Here's a policy template you can adapt to your environment. It addresses credential issuance, verification, revocation, and privacy controls while leaving room for technical flexibility.
Purpose of This Template
This policy governs how your organization issues, verifies, stores, and revokes verifiable credentials. Use it when deploying credentials for employee identity, contractor access, or customer authentication. The template assumes you're working with a credential format that supports selective disclosure and cryptographic verification, such as those aligned with emerging standards promoted by organizations like the FIDO Alliance.
The policy doesn't prescribe specific vendors or protocols. Instead, it defines requirements your implementation must satisfy, regardless of the underlying technology stack.
Prerequisites
Before customizing this template, ensure you have:
- A credential schema registry defining the attributes each credential type contains
- Issuer infrastructure with key management and signing capabilities
- Verification endpoints that can validate credential signatures and check revocation status
- Privacy impact assessment results for each credential type
- Role definitions mapping which teams can issue, verify, or revoke credentials
You'll also need buy-in from legal and compliance teams, as credential handling touches on data protection regulations and audit requirements.
The Policy Template
VERIFIABLE CREDENTIAL GOVERNANCE POLICY
1. [SCOPE](/glossary/scope)
This policy applies to all verifiable credentials issued by [ORGANIZATION]
or accepted as proof of identity, authorization, or [entitlement](/glossary/entitlement) within
[ORGANIZATION] systems.
2. CREDENTIAL ISSUANCE
2.1 Issuer Authorization
Only systems registered in the Credential Issuer Registry may sign and
issue credentials. Each issuer must:
- Maintain cryptographic keys in hardware security modules or equivalent
- Log every issuance event with holder identifier and timestamp
- Verify holder identity before issuance using [AUTHENTICATION_METHOD]
2.2 Credential Lifetime
- Employee credentials: Valid until employment termination or 365 days,
whichever is sooner
- Contractor credentials: Valid for contract duration, maximum 180 days
- Customer credentials: Valid for [DURATION] or until account closure
2.3 Attribute Inclusion
Credentials must contain only attributes necessary for their stated purpose.
Include:
- Unique holder identifier
- Issuance timestamp
- Expiration timestamp
- Issuer signature
Do NOT include:
- Social security numbers or national identifiers
- Biometric templates
- Attributes unrelated to the credential's purpose
3. CREDENTIAL VERIFICATION
3.1 Verification Requirements
Before granting access based on a credential, verifying systems must:
- Validate the issuer's cryptographic signature
- Check credential expiration
- Query the revocation registry
- Confirm the credential schema matches expected format
3.2 Selective Disclosure
When requesting credential presentation, ask only for attributes required
for the specific decision. Do not request full credential disclosure when
a subset of attributes suffices.
3.3 Verification Logging
Log all verification attempts with:
- Credential identifier (not holder PII)
- Verification outcome (valid/invalid/revoked/expired)
- Requesting system identifier
- Timestamp
4. CREDENTIAL REVOCATION
4.1 Revocation Triggers
Revoke credentials immediately when:
- Holder's employment or contract ends
- Holder reports credential compromise
- Periodic review flags credential for revocation
- Legal or compliance requirement mandates revocation
4.2 Revocation Registry
Maintain a revocation registry accessible to all verifying systems.
Update latency must not exceed [DURATION, e.g., 15 minutes].
4.3 Holder Notification
Notify holders within [DURATION, e.g., 24 hours] when their credential
is revoked, unless legal or security considerations prohibit notification.
5. PRIVACY CONTROLS
5.1 Holder Consent
Obtain explicit holder consent before issuing credentials that will be
presented to third parties outside [ORGANIZATION].
5.2 Data Minimization
Credential schemas must be reviewed quarterly. Remove attributes that are
no longer necessary for the credential's purpose.
5.3 Correlation Resistance
Where technically feasible, implement mechanisms that prevent verifiers
from correlating credential presentations across sessions.
6. AUDIT AND COMPLIANCE
6.1 Quarterly Review
Credential governance team must review:
- Issuer authorization list
- Credential schemas
- Revocation latency metrics
- Privacy impact assessments
6.2 Incident Response
Credential compromise must be treated as a security incident. Follow
[INCIDENT_RESPONSE_PLAN] for containment and notification.
Customizing the Template
Replace bracketed placeholders with your organization's specifics:
[ORGANIZATION]: Your legal entity name.
[AUTHENTICATION_METHOD]: Define how you verify holder identity before issuance. Options include Phishing-Resistant Authentication with FIDO2 authenticators, Two-Factor Authentication with Time-Based One-Time Password, or in-person identity proofing.
[DURATION] values: Set these based on your risk tolerance and operational constraints. Shorter lifetimes reduce exposure if credentials are compromised but increase reissuance overhead.
Section 2.3 attribute lists: Work with your privacy and legal teams to define what constitutes necessary versus prohibited attributes. This varies by jurisdiction and use case.
Section 5.3 correlation resistance: If your credential format supports unlinkable presentations, enable this feature. If not, document the limitation in your privacy impact assessment.
Section 6.2 incident response plan: Link to your existing security incident procedures. Ensure they cover credential revocation workflows and holder notification timelines.
Validation Steps
After customizing the policy:
Map to existing frameworks: Cross-reference your policy against NIST SP 800-63-3 and any voluntary codes of conduct relevant to your industry. Identify gaps.
Test revocation latency: Issue a test credential, revoke it, and measure how long verification systems take to recognize the revocation. If it exceeds your policy threshold, adjust your registry architecture.
Conduct a tabletop exercise: Simulate a credential compromise scenario. Walk through sections 4.1, 4.3, and 6.2 with your incident response team. Note any procedural gaps.
Review with legal: Have your legal and compliance teams confirm the policy satisfies data protection requirements in your operating jurisdictions. Pay special attention to sections 2.3 and 5.
Audit issuer configurations: For each system in your Credential Issuer Registry, verify it meets the requirements in section 2.1. Document any exceptions and remediation timelines.
Your policy is a living document. As verifiable credential standards mature and industry codes evolve, revisit sections 3 and 5 annually to incorporate new privacy-enhancing techniques and verification methods.
