Chapter 16: Using verifiable credentials for authorization

Introduction

The introduction explains why ACME struggles to authorize people and attributes outside its identity systems and presents verifiable credentials as a way to use attestations from trusted external issuers.

• External account life cycle burden: Explain why ACME’s internal account model is difficult to use for non-employees and how delayed partner updates can leave temporary access in place too long.
  Why it matters: The account life cycle problem explains why ACME needs another way to handle external access.
• Federation and external authority limits: Explain why federation does not cover all of ACME’s partners and why ACME needs authorization facts maintained by outside organizations.
  Why it matters: ACME needs access to outside organizations’ assertions without requiring every partner to run a federation integration.
• Verifiable credentials as external attestations: Describe how ACME proposes to use verifiable credentials in authorization decisions instead of relying on its own record of each person.
  Why it matters: This shifts the basis for an access decision from ACME-held identity records to relevant claims from trusted issuers.

Key terms: internal directory, temporary accounts, deprovisioning, federation, identity provider, authoritative statements, verifiable credentials, portable attestations, trusted issuers, attributes

16.1 Why authorization needs verifiable credentials

This section explains why ACME needs verifiable credentials to bring externally held facts into authorization decisions.

• External authorization context gap: Explain why ACME cannot rely on its internal systems for every access decision involving external people.
  Why it matters: An access decision needs reliable facts even when ACME is not the authority that holds them.
• Limits of existing approaches: Distinguish why local accounts and federation do not fully solve ACME’s external-authorization problem.
  Why it matters: These limitations explain why ACME needs another way to obtain externally held facts.
• Credentials as trusted signals: Describe how verifiable credentials can supply external facts to ACME’s existing authorization approach.
  Why it matters: Credentials let authorization use facts from the organizations best placed to attest to them.

Key terms: authoritative internal systems, external people, life cycle events, local accounts, federation, independent authorities, verifiable credentials, external attestations, trusted signals, authorization context

16.2 How verifiable credentials work

This section explains how issuer-signed credentials let people carry attributes for authorization while allowing ACME to verify their integrity and assess the issuer’s authority.

• Portable issuer-signed attributes: Trace how an issuer puts claims about a subject into a signed credential, gives it to the subject, and lets the subject present it when requesting access.
  Why it matters: This explains why carrying a credential does not mean the holder is the source of its claims.
• Cryptographic confidence and issuer trust: Distinguish ACME’s cryptographic confidence that a presented credential is authentic and unaltered from its trust in the issuer’s authority to make the claims.
  Why it matters: Checking a signature and deciding whether to rely on the signer answer different questions.
• Authorization-relevant credential contents: Describe the credential information this section identifies as relevant to authorization, including its claims, validity period, revocation-check information, and proof; explain how claims serve as policy-engine attributes.
  Why it matters: These fields show what ACME can check and what information a policy engine can use.

Key terms: verifiable credential, issuer, subject, claims, attributes, confidence, trust, issuer’s signature, issuer’s authority, credentialStatus

16.2.1 Credential presentation

Explains how a holder presents a verifiable credential, what the verifier can establish, and how verified claims become authorization context.

• Credential presentation and trust: Trace the roles of issuer, holder, and verifier when a credential is presented, and explain what verification establishes before ACME applies policy.
  Why it matters: It separates carrying a claim from providing the evidence ACME needs to trust and use it.
• Wallet and person distinction: Distinguish proof that a credential was issued to a wallet from evidence connecting that wallet to the person presenting it.
  Why it matters: A valid credential presentation alone does not prove which person controls the presenting wallet.
• Cross organization attribute sharing: Explain why credential presentations let ACME use externally issued attributes without integrating each partner’s identity system.
  Why it matters: ACME can evaluate partner-supplied facts without maintaining a separate identity integration for every partner.
• Verified claims as context: Describe how ACME uses verified credential claims in an authorization decision.
  Why it matters: Verification makes external claims usable by ACME’s existing policy-based authorization process.

Key terms: trust triangle, issuer, holder, verifier, presentation, revoked, wallet, biometric unlock, identity proofing, attributes

16.2.2 Example: Contractor access using verifiable credentials

A contractor audit example shows how ACME uses verifiable credentials to make a limited, time-bounded access decision without creating an account for the contractor.

• Contractor credential claims: Describe the two claims Angela presents for her audit request and why ACME needs them.
  Why it matters: The credentials supply facts about an external contractor that ACME can use in its access decision.
• Verification and policy decision: Trace what the PEP verifies and what the PDP evaluates before Angela receives access.
  Why it matters: A valid presentation supplies evidence, but ACME’s policies still determine whether this particular request is allowed.
• Limited access without onboarding: Explain the access Angela receives if the conditions pass and the operational benefit for ACME.
  Why it matters: ACME can authorize a short engagement without taking on routine account management for the contractor’s personnel.

Key terms: wallet, presentation, credentials, AuditsRUs, CISA-R certification, Policy Enforcement Point (PEP), Policy Decision Point (PDP), claims, expired, revoked

16.3 Trusting credential issuers

This section explains why ACME must trust a credential issuer’s authority, not just verify a credential’s authenticity, before using its claims in authorization decisions.

• Issuer authority versus authenticity: Distinguish cryptographic confidence that a credential is genuine and unaltered from trust that its issuer is qualified to make the particular claim.
  Why it matters: A genuine credential does not, by itself, make its claims authoritative for an access decision.
• Governance authority and trust diamond: Explain what the governance authority adds to the holder–issuer–verifier relationship and how its published framework helps a verifier assess issuers, using NISA as the example.
  Why it matters: The framework gives ACME a basis for deciding which external issuers have authority it can rely on.
• Advance issuer trust verification: Describe when and by whom ACME verifies an issuer’s trustworthiness before using its credentials in policy evaluation.
  Why it matters: Issuer trust needs to be established as an ongoing governance responsibility, not assumed when a credential arrives.

Key terms: verifiable credentials, issuer, cryptography, authoritative external claims, governance framework, trust diamond, governance authority, NISA, accredited security auditor, internal governance

16.3.1 Example: ACME onboards AuditsRUs as a trusted issuer

The section shows how ACME vetted AuditsRUs as a credential issuer, recorded the scope of that trust, and later used it to assess Angela’s credentials.

• AuditsRUs accreditation review: Describe how Tim evaluated whether AuditsRUs should become a trusted issuer, using NISA’s governance framework and AuditsRUs’ accreditation credential.
  Why it matters: An issuer’s claims are useful only after ACME has established who the issuer is and what it is accredited to assert.
• Recorded issuer trust scope: Explain what ACME recorded after the review and how the scope of its trust in AuditsRUs was defined.
  Why it matters: Recording the issuer and its permitted claims lets ACME apply the vetted trust relationship when credentials are presented later.
• Credential authenticity and authority: Distinguish what cryptography established about Angela’s credentials from what ACME’s prior trust in their issuers established.
  Why it matters: A genuine credential does not, by itself, make its issuer’s claims authoritative for ACME.

Key terms: NISA governance framework, accreditation credential, validity period, revoked, internal registry of issuers, governance system, trust store, employment and role credentials, cryptography, Angela’s wallet

16.3.2 Building and maintaining ACME’s trust store

This section explains how ACME records issuer authority by credential type, keeps those trust decisions current, and makes them available to authorization systems.

• Scoped issuer trust decisions: Explain what ACME’s trust store records and why trust is limited to particular issuers and credential types. Describe which credentials ACME accepts from AuditsRUs and NISA.
  Why it matters: Scoping issuer trust prevents an organization from asserting claims outside its recognized authority.
• Ongoing accreditation validity: Explain what ACME must maintain after accepting NISA’s accreditation process and what happens if NISA revokes AuditsRUs’s accreditation.
  Why it matters: A sound credential signature alone cannot establish that the issuer still has the authority a policy requires.
• Trust signals for authorization: Describe how ACME makes trust-store decisions available during authorization and why it keeps issuer lists out of individual policies.
  Why it matters: A shared trust decision lets authorization components use credential claims without maintaining separate issuer lists.

Key terms: trust store, issuer, credential types, scope of trust, accreditation, revoked, cryptographically valid, governance layer, Policy Information Points (PIPs), structured signals

16.4 Credential freshness, revocation, and assurance

This section explains why ACME checks credential freshness and revocation at presentation time, even when it trusts the issuer and the credential’s signature is valid.

• Current credential status: Explain why trusting an issuer and verifying a credential’s signature are not enough for authorization. A credential must still reflect a current fact when it is presented.
  Why it matters: A genuine credential can otherwise authorize someone whose circumstances have changed.
• Expiration and revocation checks: Distinguish the freshness provided by expiration dates from the protection provided by revocation, and describe how ACME can check revocation before using credential claims.
  Why it matters: Revocation lets ACME respond to changes that occur before a credential expires.
• Revoked employment access: Trace what happens when Brian presents a revoked employment credential, and explain the operational benefit of relying on checked external credentials.
  Why it matters: The issuer’s status update can remove access without ACME maintaining a separate employment record.

Key terms: cryptographically valid, freshness, assurance level, current status, expiration date, revocation information, real-time status endpoint, signed revocation list, authorization engine, revocation status

16.5 Requesting verifiable credential presentations

This section explains how ACME requests policy-relevant claims from a holder’s wallet, verifies the resulting presentation, and passes normalized authorization context to the PDP.

• Claim-based presentation flow: Trace how the PEP requests the claims needed for a decision and the holder’s wallet creates a signed presentation from one or more credentials. Distinguish that presentation from the underlying credentials.
  Why it matters: The same request can be satisfied by relevant claims from different credentials without disclosing everything in them.
• Verified claims as policy context: Explain what happens to a presentation before the PDP evaluates a request, and distinguish the PDP’s input from the raw credential format.
  Why it matters: Normalization lets policies evaluate authorization meaning without handling credential formats and verification details.
• Benefits of requesting attributes: Justify why ACME requests specific attributes instead of specific credentials, including the effects on disclosure and dependence on external issuers.
  Why it matters: ACME can adapt its authorization needs across products while asking holders to reveal only relevant information.

Key terms: attribute query, claims, holder’s wallet, credential presentation, selective disclosure, PEP, PDP, PIP, issuer trust, revocation status

16.6 Using verifiable credentials with policies

This section explains how verified credential claims become ordinary authorization attributes that ACME’s policies can evaluate without handling credentials directly.

• Credential claims as policy context: Trace how a credential presentation becomes context for a policy decision: the PEP verifies it, extracts and normalizes relevant claims, and sends the resulting attributes to the PDP.
  Why it matters: It shows where credential trust checks end and ordinary policy evaluation begins.
• Policies independent of credential mechanics: Explain how policies use credential-derived attributes alongside other context and why they need not know which credentials supplied those attributes.
  Why it matters: The same policy model can use credential evidence without embedding credential-handling rules in each policy.

Key terms: PEP, PDP, credential presentation, claims, internal attribute schema, credential-derived attributes, context, policies, trust mechanisms, authorization logic

16.6.1 Allow access only to auditors from accredited firms

The section shows how ACME uses credential-derived employer and certification attributes to restrict audit-log access without embedding its list of trusted firms in the policy.

• Auditor access and trusted firms: Explain that audit-log access requires an auditor’s employer to be a recognized firm and the auditor to have the proper certification. Describe why ACME keeps the trusted-firm list in its trust store rather than in the policy.
  Why it matters: Keeping trusted firms outside the policy lets ACME change whom it trusts without rewriting the access rule.

Key terms: VC-derived attributes, principal’s employer, certification status, trust store, NISA

16.6.2 Require current certification from an accredited authority

This section shows how ACME requires current, trusted certification for sensitive documents while keeping credential verification details out of authorization policies.

• Sensitive document certification requirements: Explain the added assurance required for access to sensitive documents: the principal must hold the required certification from a trusted certification body, and the credential must not have expired.
  Why it matters: Sensitive documents require evidence of current qualifications, not just an ordinary access permission.
• Credential verification and policy roles: Trace how ACME’s trust store, PIP, PEP, and PDP divide the work of checking credentials and making an access decision.
  Why it matters: Separating verification from policy evaluation lets each component handle the information it is meant to handle.
• Stable policies across credential changes: Justify keeping issuer names, credential schemas, and claim names out of policies, and describe how trust-store and mapping changes accommodate new issuers or formats.
  Why it matters: ACME can work with changing credential ecosystems without repeatedly changing its access policies.

Key terms: sensitivity, normalized resource attribute, principal, trusted certification body, certification, trust store, PIP, PEP, PDP, normalized attributes

16.7 Protocols and ecosystem integration

This section explains how different verifiable credential protocols can feed the same authorization workflow through a protocol-neutral verification layer.

• Credential ecosystem layers: Describe the roles of issuance protocols, presentation protocols, and wallet standards, and how they support an authorization request.
  Why it matters: These layers explain how a credential gets from its issuer into a usable authorization decision.
• Two credential protocol families: Distinguish the DID-based W3C credential approach from OpenID for Verifiable Credentials at the level described here.
  Why it matters: The protocols differ in infrastructure and interaction, not in the kind of verified claims authorization needs.
• Protocol-neutral verification boundary: Trace how ACME’s PEP verification service turns presentations from different protocols into attributes for the PDP, and explain why policies need not change with the protocol.
  Why it matters: ACME can work with partners using different credential ecosystems without making each protocol a separate policy design.

Key terms: issuance protocols, presentation protocols, wallet standards, PEP, PDP, W3C Verifiable Credentials Data Model, DID-based identifiers, DID resolution, OpenID4VCI, OpenID4VP

16.8 Applying verifiable credentials across ACME’s products

This section shows how ACME can apply a consistent verifiable-credential authorization flow across its products.

• Reusable credential authorization flow: Explain how verifiable credentials provide trusted context for ACME’s policy engine without ACME managing accounts for every external participant. Trace the PEP’s attribute request, the holder’s presentation, and the PDP’s decision, noting that protocols may vary while this flow stays consistent.
  Why it matters: The same decision pattern can support different external participants and products without making ACME manage an account for each one.

Key terms: verifiable credentials, PEP, holder, presentation, PDP, normalized claims

16.8.1 Supplier portal: Representing supplier authority across multi-tier relationships

The section shows how ACME uses verifiable credentials to authorize supplier employees across a multi-tier supply chain without managing their accounts directly.

• Supplier credential verification flow: Trace how ACME requests and checks a supplier employee’s employment and delegated-authority claims, then passes normalized attributes to the PDP for an access decision.
  Why it matters: Credential evidence can inform a policy decision without ACME maintaining the worker’s identity or role itself.
• Purchase order access conditions: State the conditions that must hold before a supplier employee can view or update a purchase order.
  Why it matters: Proof of employment is not enough unless the supplier has current authority for the specific work.
• Multi-tier authority benefits: Explain why credential-based authority fits the manufacturer–supplier–employee relationship better than manufacturer-managed worker accounts in this example.
  Why it matters: Matching authorization to the business relationship reduces the work and risk of maintaining accounts for another organization’s workers.

Key terms: PEP, attribute query, claims, normalized attributes, PDP, supplier listed on the order, delegated authority, delegation credential, expired, revoked

16.8.2 Clinic integration: Clinicians from external organizations

The section shows how ACME Health can use verifiable credentials to grant external clinicians access based on trusted professional, clinic, and patient-care information without long-term accounts.

• External clinician credential verification: Describe what information ACME Health requests when an external clinician seeks access and how it verifies the presentation and trusts its issuers.
  Why it matters: This explains how ACME can evaluate a clinician from outside its internal identity system.
• Clinician access policy conditions: Explain the example policy conditions for clinician access and why this approach avoids long-term accounts.
  Why it matters: These conditions tie access to the clinician’s current authority and involvement with the patient.

Key terms: PEP, professional license, affiliation, protocol-flexible verification layer, jurisdiction-specific accreditation frameworks, relevant jurisdiction, valid business relationship, patient’s care team, long-term accounts

16.8.3 Field technicians: Employer-issued scope-of-work credentials

This section shows how ACME uses service-partner-issued credentials to authorize field technicians without maintaining its own technician directory.

• Employer-issued credential decision flow: Trace how a service partner’s credentials supply a technician’s employment, role, and service scope; the PEP requests policy-relevant attributes, the verification layer validates the credentials, and the PDP evaluates policy.
  Why it matters: It shows how ACME can make access decisions using authority asserted by a technician’s employer.
• Technician access scope limits: Explain how policies limit technicians by product certification and assigned region, and impose additional requirements for high-risk operations. Describe why this lets ACME support dispersed field work without its own technician directory.
  Why it matters: The example connects credential-backed policy checks to practical limits on what a partner’s technician can do.

Key terms: service partners, credentials, PEP, verification layer, PDP, attributes, product certifications, assigned region, employer authorization, safety-training credential

16.8.4 Customer Collaboration Cloud: Project-scoped roles in a multi-tenant platform

This section shows how C³ uses tenant-issued project-role credentials to authorize collaboration without managing each tenant’s customer accounts or roles.

• Tenant-Controlled Project Roles: Explain how tenants issue and maintain project-role credentials for invited participants, and why C³ does not need its own role directory or account store for those participants.
  Why it matters: Tenant-controlled credentials let C³ reflect changing project assignments without taking over each tenant’s identity management.
• Credential Verification Flow: Trace how C³ obtains and verifies the credential claims used for a project-space access decision.
  Why it matters: A stated project role is useful for authorization only after C³ verifies that it applies to the right tenant and project and is still valid.
• Project Role Permissions: Describe how C³ policies can give different project roles different permissions, using examples from the section.
  Why it matters: The project role becomes an input to policies that distinguish what collaborators may actually do.

Key terms: C³, tenant, project-role credentials, role life cycle, wallets, PEP, attribute query, verification layer, normalized attributes, PDP

16.9 Operational and governance considerations

Verifiable credentials expand the context used for authorization, so their integration requires operational discipline and governance as issuers, credentials, and workflows change.

• Governance of credential context: Explain why adding verifiable credentials to authorization requires more than protocol support or policy design. Describe how they broaden the context ACME must manage as issuers, credentials, and workflows evolve.
  Why it matters: A credential can supply authorization context, but managing that context remains an ongoing responsibility.

Key terms: verifiable credentials, operational discipline, governance structures, context surface, contextual signals

16.9.1 Deciding when to use verifiable credentials

This section explains when verifiable credentials are a good fit for authorization and when traditional accounts may remain appropriate.

• External claims and assurance: Explain why verifiable credentials suit decisions that depend on authority outside ACME, including claims from multiple organizations and assurance about the source and integrity of attributes.
  Why it matters: The source of a claim can be as important to an access decision as the identity of the person presenting it.
• Fit with changing relationships: Describe why verifiable credentials can fit changing participants and access across many organizations without continually copying external directory data, and contrast that with stable internal employees.
  Why it matters: Choosing an integration approach by relationship type avoids treating every access need as the same problem.

Key terms: verifiable credentials, externally issued claims, authoritative sources, assurance, credential-based access, federation, directory synchronization, traditional account life cycle, trust model

16.9.2 Failure modes and fallback paths

This section identifies common failures in credential-based access and explains how ACME should guide users toward resolution while keeping fallback access controlled.

• Credential Access Failure Modes: Describe why credential-based access can fail, distinguishing an intended denial for an expired or revoked credential from problems presenting a credential or trusting its issuer.
  Why it matters: Different failures call for different responses, and a correct denial should not be mistaken for a broken system.
• Resolution and Controlled Fallbacks: Explain how ACME should help users resolve credential problems and what limits it should place on exception-based access.
  Why it matters: A usable recovery path need not turn a credential failure into unrestricted access.

Key terms: holder, wallet, claims, assurance model, issuer, presentation flows, fallback workflows, exception-based access, temporary permits, break-glass procedures

16.9.3 Governance responsibilities

The section assigns governance and operational responsibilities for using verifiable credentials while keeping authorization policies stable as trust decisions change.

• Governance and policy separation: Explain how ACME can change which issuers and credential types it trusts without rewriting authorization policies or application code.
  Why it matters: ACME can update and review trust decisions without making each change an application or policy rewrite.
• Credential governance team responsibilities: Describe how ACME divides responsibility for issuer trust, credential-related signals, presentation handling, and policy expression among its teams.
  Why it matters: Clear ownership connects credential trust decisions to access checks without tying policies to particular issuers or formats.

Key terms: governance, trusted issuers, trust framework, policy, identity team, integration and signals team, PIP, authorization platform teams, PEPs, PDP

16.9.4 Rolling out verifiable credentials incrementally

This section describes ACME’s gradual rollout of credential-based authorization, from a narrow pilot through verification, expansion, and ongoing oversight.

• Incremental credential rollout: Describe how ACME starts with external auditors, stabilizes credential verification, and then expands to adjacent use cases while preserving continuity in existing systems.
  Why it matters: A staged rollout lets ACME broaden credential-based access without disrupting existing systems.
• Production monitoring and governance: Explain how ACME checks credential-based authorization in production and adapts governance as issuers change.
  Why it matters: Monitoring and governance updates help ACME keep credential-based decisions working as issuers evolve.

Key terms: external auditors, verification service, trust store, credential-based authorization, telemetry, decision logs, credential-based attributes, assurance levels, trust-store entries, policy logic

16.10 Summary