An organization may accept an auditor’s employment credential and a separate professional certification without creating either identity itself. A trust store makes that decision reusable: it records which external issuers are authoritative for which credential types, so verified claims can support access decisions. section 16.3.1 section 16.3.2
A trust store is a governance artifact, not merely a collection of public keys. Each entry captures an issuer, the credential types accepted from it, and the scope of that authority. Trusting an audit firm for employment and role credentials does not imply trusting it to issue professional certifications; a certification authority can be trusted for the latter instead. section 16.3.2
A dependable trust store separates durable trust decisions from request-time credential checks:
- Evaluate an issuer’s governance framework, accreditation, and authority before adding it for defined credential types. section 16.3.1 section 16.3.2
- Maintain entries as accreditations change; periodic checks or subscriptions to a trust registry can update recognized issuers. section 16.3.2 section 16.9.4
- At access time, verify signatures, issuer authorization, expiration, and revocation status before using credential-derived attributes. section 16.4 section 16.7
- Normalize verified claims into attributes so authorization policies express business requirements without credential-format or issuer-specific logic. section 16.10 section 16.6.2
This separation keeps governance adaptable and policy stable. Identity teams manage trusted issuers, assurance levels, and acceptable credential types; integration teams maintain issuer metadata, revocation endpoints, and attribute mappings. A policy decision point evaluates normalized attributes, while a policy enforcement point validates presentations and applies trust-store data during request assembly. section 16.6.2 section 16.9.3
Auditor access without hardcoded firms
To view audit logs, a person must be employed by a recognized auditor firm and hold a CISA-R certification. The trusted-firm set belongs in the trust store, while the policy evaluates employer and certification attributes. Adding another NISA-accredited firm changes trust-store data and mappings, not the policy itself. section 16.6.1 section 16.6.2
permit(
principal,
action == Action::Audit::"view-log",
resource is Audit::Log
)
when {
principal.employer in context.trusted_auditor_firms
&& principal.certification == "CISA-R"
};
This policy listing shows the policy consuming a trusted-auditor-firms context value rather than naming individual issuers directly. section 16.6.1
Trust stores support credential-based authorization across multiple protocols and wallet types when the verification layer performs consistent issuer, signature, expiration, and revocation checks. Protocol differences remain at the presentation layer; policies can remain focused on normalized attributes. section 16.10 section 16.7
