Credential Engine Issuer Identity Registry Service Governance Framework

1. IIR Registry Overview and Purpose

The Credential Engine Issuer Identity Registry (IIR) is an open, public-benefit infrastructure that establishes a trusted, verifiable record of organizations that offer and issue credentials to people. The IIR focuses on substantiating the identity of credential issuers, enabling consistent, machine-readable identification of legitimate issuers across learning and work ecosystems. In this document, “credentials” is used broadly to include “qualifications,” recognizing that many jurisdictions use the term “qualification” to refer to certain types of credentials.

Issuer substantiation may be demonstrated through different forms of evidence depending on organizational context. For some organizations, this may include formal legal authorization or statutory authority. For others, legitimacy may be established through verified organizational existence, governance, web domain control, operational activity, and/or demonstrated credential issuance practice. The IIR does not impose a single, universal verification requirement across all issuers. Instead, eligibility, governance expectations, and verification requirements are defined through policy and implemented through the IIR verification process.

The IIR’s objectives are to:

• • • Provide a reliable source of truth for verifying issuer identity through Decentralized Identifiers (DIDs) linked to digital credentials.
    • Support interoperability among verifiable credential ecosystems.
    • Strengthen trust, accountability, and data integrity in credential exchange and verification.
    • Ensure open participation and transparent governance across education, employment, and industry sectors.

Operationally, the IIR is designed to function as a trusted registry service governed by clearly defined policies for eligibility, verification, security, privacy, and sustainability. It emphasizes machine-readable data formats, open standards, and alignment with global best practices for verifiable credential infrastructures.

1.1 Purpose and Scope of the IIR Service

This section defines the purpose, scope, and functional boundaries of the Credential Engine Issuer Identity Registry (IIR) service. It explains what the IIR is designed to do, which issuers are in scope, how the service relates to the Credential Registry, and the criteria organizations must meet to participate as verified issuers within global credential ecosystems.

1.1.1 Purpose

The Credential Engine Issuer Identity Registry (IIR) provides a reliable, machine-readable service for substantiating the verified identity of credential issuers within learning and work ecosystems. Its purpose is to enable transparent, verifiable identification of organizations that issue digital, verifiable credentials to people, using Decentralized Identifiers (DIDs) associated with the credentials they issue.

1.1.2 IIR Integration with the Credential Registry

The IIR service is fully integrated with the Credential Registry publishing system, providing added value and benefit to both issuers and data users. Through this integration, issuers approved for inclusion in the IIR service are connected to rich, structured organization records in the Credential Registry that describe the organization, its identifiers, and the credentials it owns and/or offers to people.

The Issuer Identity Registry (IIR) and the Credential Registry are different but complementary services operated by Credential Engine, each serving a distinct role within global credential transparency and verification ecosystems.

IIR: The IIR functions as a verification service, using a Decentralized Identifier (DID) as the authoritative identifier for cryptographically verifying issuer identity. Each issuer record in the IIR includes both a DID, used for cryptographic verification of issuer identity, and a Credential Transparency Identifier (CTID), which links the verified issuer to its corresponding organization record in the Credential Registry.

Credential Registry: The Credential Registry functions as a descriptive, linked open data registry, publishing rich, structured information about organizations and the credentials they own and/or offer using the Credential Transparency Description Language (CTDL) and JSON-LD. Credential Registry data are accessible through multiple data consumption options, including APIs, bulk downloads, and the Credential Finder, a public tool for exploring published registry data.

This linkage enables verifiers to confirm issuer authenticity through the IIR while retrieving descriptive organizational and credential information from the Credential Registry—without duplicating data or conflating verification and descriptive functions across services.

1.1.3 In-Scope Issuers

The scope of the IIR service includes issuers of achievement credentials described using the Credential Transparency Description Language (CTDL). It covers all CTDL-defined credential classes and types representing learning, employment, and professional achievements earned by individuals. Participating issuers may include public or private organizations across education, training, assessment, and credentialing domains in any industry or sector globally. This includes entities such as employers, government agencies, industry certification and licensing bodies, professional associations, and education or training providers, regardless of national jurisdiction.

1.1.4 Out-of-Scope Issuers

The IIR service excludes issuers who only issue credentials that are not associated with a person’s learning or work-related achievements. This includes credentials used solely for system or software access, device authentication, identity verification (such as passports or driver’s licenses), or to indicate membership, affiliation, or status (for example, press passes or employee identification badges), where no assessed or verified learning or work-related achievement is represented.

1.1.5 Participation Criteria

Participation in the IIR service is limited to organizations that meet Credential Engine’s governance and verification requirements for issuer identity substantiation.

1.2 Subject Matter Focus of the Registry

The Issuer Identity Registry (IIR) is limited in scope to organizations that issue credentials to people. Its subject-matter focus is organizational identity verification within learning and work ecosystems. The IIR ensures that only credential issuers—those responsible for awarding verifiable learning, employment, or professional achievements—are represented as trusted entities.

While some issuer registries may restrict participation to specific sectors, jurisdictions, or credential types, the Credential Engine IIR is designed to be globally inclusive, supporting issuers across countries, industries, and systems that meet the governance and verification requirements defined in Section 3: Issuer Information and Verification.

1.2.1 Included Issuer Domains

• • • Education and training providers: Public and private organizations offering learning opportunities across grade levels, and throughout postsecondary to adult, continuing, and professional education contexts. This includes organizations awarding academic credit, occupational credentials, or other forms of non-credit, skill- or competency-based achievements. Participation is not limited to traditional academic providers.
    • Assessment organizations: Entities conducting assessments or recognition of prior learning (RPL/CPL) that result in credentials, assessment records or scores, verifications, or documented achievements.
    • Occupational credentialing and licensing bodies: Organizations responsible for defining, assessing, and verifying competencies or qualifications required for entry or practice in specific occupations or professions. These bodies may issue certifications, licenses, or other occupational credentials that include a status indicator, for example, active, expired, or revoked, to reflect current standing or validity.
    • Employers and workforce organizations: Companies, employer consortia, and workforce development entities issuing credentials to employees, apprentices, or other participants in professional or technical training programs or other types of work-based learning.
    • Government agencies: Public authorities issuing credentials tied to learning, employment, occupational qualification, or workforce development systems.
    • Professional associations and industry groups: Organizations that establish standards and oversee professional or industry-based credentials when those credentials represent verified competencies, qualifications, or achievements.
    • Community, service, and volunteer-based organizations: Organizations that offer volunteer, service-learning, or community engagement opportunities and issue credentials recognizing skills, competencies, service-based learning outcomes, or demonstrated contributions.
    • Organizations issuing credentials for demonstrated expertise or instructional contribution: Entities that recognize and credential individuals for demonstrated expertise, instructional activity, mentoring, facilitation, or teaching contributions that are not issued as occupational licenses, certifications, or professional credentials.

1.2.2 Organizations out of scope for inclusion in the IIR service

• • • Membership or affiliation organizations: Organizations whose credentialing activities are limited to only issuing credentials that indicate membership, affiliation, or status, without associated assessed or verified learning or work-related achievement.
    • Access and technical authorization providers: Organizations that only issue credentials used solely for system or software access, device authentication, or other forms of technical authorization.
    • Civil identity authorities: Organizations that only issue civil or government identity documents unrelated to learning or work-related achievements, such as passports or driver’s licenses.
    • Non-individual credential issuers: Organizations that only issue credentials not intended for individuals, including those issued to other organizations, software agents, systems, or machines.
    • Quality assurance and oversight bodies: Organizations whose credentialing activities are limited to only issuing quality assurance, oversight, authorization, or recognition credentials, such as institutional or programmatic accreditation, where the credential applies to an organization, program, or system rather than to an individual’s learning or work-related achievement.

1.3 Funding Model and Sources

The sustainability of the IIR service depends on transparent, diversified, and mission-aligned funding that ensures long-term reliability. All funding must support continued operation and governance without compromising Credential Engine’s neutrality, influencing issuer inclusion criteria, or limiting open participation.

1.3.1 Funding Sources

• • • Credential Engine core support: Baseline operational and maintenance costs funded through Credential Engine’s organizational budget, which includes philanthropic grants, public-sector partnerships, services, and mission-related contributions.
    • Public or private grants and contracts: Targeted funding supporting specific initiatives such as interoperability pilots, standards alignment, or global trust-infrastructure development.
    • IIR Service–Direct Contributions: Voluntary financial or in-kind contributions from government agencies, regional consortia, or industry alliances that directly support the IIR service or benefit from its integration into broader trust ecosystems.
    • Direct participation fees: A structured fee model may be established to recover costs associated with registry participation, verification, or technical integration. Any such fee structure would be applied transparently, equitably, and consistent with Credential Engine’s public-benefit mission.
    • Sponsorship or project-specific services: Transparent, limited-scope sponsorships or technical support agreements that enhance the IIR service while maintaining neutrality and public-benefit status.

This funding approach ensures that the IIR service remains an open, sustainable component of Credential Engine’s global transparency infrastructure.

1.4 Business Model and Fee Structure

The Issuer Identity Registry (IIR) service operates as an open, public-benefit resource designed to ensure equitable access and participation. The business and participation models described here represent potential approaches that may evolve over time in accordance with the IIR governance policy.

At present, fees are established for inclusion in the IIR service. Fees for cost-recovery, all related terms, conditions, and policies will be publicly documented and implemented in a manner consistent with Credential Engine’s public-benefit mission and governance principles.

1.4.1 Participation Models

Participation in the IIR service may be supported through one or more of the following models depending on how operational costs are covered and the level of support required by participating organizations.

• • • Open Model: Allows for no-cost participation for credential issuers that meet the governance and verification criteria for inclusion in the IIR service, where the costs of operating and maintaining the IIR are covered by a third party (for example, through grant funding, sponsorship, or system-level investment).
    • Cost-Recovery Model: Applies when third-party funding is not available and participation requires recovery of costs associated with baseline participation including: identity verification, registry operations, ongoing maintenance, or technical integration.
    • Value-Added Services Model: Applies when participating organizations request additional or optional services beyond baseline participation. These services may include integration support, sandbox testing environments, or data analytics and are offered on a fee-based basis.

Together, these models ensure that participation in the IIR service remains open, trusted, and sustainable. All financial considerations are implemented transparently and in alignment with Credential Engine’s public-benefit mission and IIR governance policy.

1.5 Use and Storage of Private Individuals’ Data

The IIR service is intentionally designed to avoid the collection or storage of information about credential recipients. Its purpose is solely to verify and represent the identity of organizations that issue digital, verifiable credentials, not the individuals who earn them.

The IIR service includes organizational data needed to establish and maintain verified issuer identity records.

1.5.1 Data Protection Principles

• • • No learner or recipient data: The IIR service does not collect, store, or process data about people who receive digital credentials.
    • Minimal necessary data: Only information essential to support issuer account administration and verification is maintained.
    • Privacy and security alignment: The IIR service operates in compliance with Credential Engine’s organizational privacy policy and applicable data protection requirements. Individual contact details are not publicly displayed in the IIR service or the Credential Registry.

The IIR service functions strictly as an organizational trust infrastructure, protecting individual privacy while maintaining transparency and accountability for participating credential issuers.

2. Governing Parties and Oversight

Effective governance of the IIR service ensures that its operations remain transparent, accountable, and aligned with Credential Engine’s public-benefit mission. Oversight is exercised through clearly defined roles, documented decision-making authority, and established mechanisms for communication, dispute resolution, and continuous improvement.

Governance of the IIR is designed to:

• • • Uphold public trust in the registry and its verified issuer data.
    • Ensure consistent, standards-based operation and policy enforcement.
    • Provide a transparent structure for accountability, appeals, and ongoing service quality.

2.1 Credential Engine’s Mission

Credential Engine is a non-profit organization based in the United States dedicated to advancing transparency, comparability, and trust across global credential ecosystems.

Our Mission: Credential Engine’s mission is to map the credential landscape with clear and consistent information, fueling the creation of resources that empower people to find the pathways that are best for them.

Our Vision: We envision a future where millions of people worldwide have access to clear information about credentials, qualifications, and skills, unlocking opportunities for learning, advancement, and meaningful careers.

How we accomplish our Mission and Vision:

• • • Building common infrastructure and language — creating open data standards such as the Credential Transparency Description Language (CTDL) and services such as the Credential Registry and IIR service.
    • Collaboration — working with education, workforce, government, and industry partners to ensure interoperability and transparency.
    • Empowerment — enabling learners, credential providers, employers, and policymakers to make informed decisions using consistent, open data.

2.2 Advisory Structure

Governance of the Issuer Identity Registry (IIR) service is the responsibility of Credential Engine, which provides full oversight and accountability for its operation. The organization ensures that all IIR policies, procedures, and technical functions are managed in alignment with its mission, values, and governance framework.

Oversight is exercised through Credential Engine’s leadership and staff, who maintain operational integrity, ensure compliance with governance policies, and coordinate with advisory groups and partners to promote transparency, accountability, and stakeholder engagement.

2.2.1 Credential Engine’s Governance Ecosystem

Credential Engine maintains a coordinated governance structure that includes its Board of Directors, Leadership Team, Staff and Consultants, Advisory Groups, Councils, and Partners. Together, these entities advance Credential Engine’s mission to promote global credential transparency and open-data interoperability.

Within this structure:

• • • The CTDL Advisory Group (CAG), CTDL Team, and CTDL Task Groups provide ongoing technical and policy guidance for the evolution of the Credential Transparency Description Language (CTDL) and related infrastructure.
    • Credential Engine’s Leadership and Technical Teams ensure operational continuity, policy enforcement, and alignment between governance decisions and technical implementation.

2.2.2 IIR Advisory Group

As part of this governance framework, Credential Engine will establish a standing IIR Advisory Group. This group will provide strategic, policy, and technical advice specific to the IIR service, including recommendations on interoperability, data quality, and trust frameworks.

The IIR Advisory Group serves in an advisory capacity only. It does not hold operational or decision-making authority. Ultimate responsibility and decision-making authority remain with Credential Engine.

2.3 Responsibilities of the Governing Parties

Credential Engine is responsible for the overall governance, operation, and continuous improvement of the Issuer Identity Registry (IIR) service. All oversight activities are carried out in accordance with Credential Engine’s mission, governance framework, and related terms of use, privacy policy, and policies for the Credential Registry and the Credential Transparency Description Language (CTDL).

2.3.1 Credential Engine’s Responsibilities

• • • Operational oversight: Manage day-to-day operations of the IIR service, ensuring compliance with established policies, verification criteria, and technical standards.
    • Policy development and maintenance: Establish, review, and update governance documents, policies, and procedures to reflect evolving best practices and stakeholder needs.
    • Advisory group convening: Convene and maintain the IIR Advisory Group in accordance with Credential Engine’s established processes and procedures, ensuring transparent membership selection, operation, and publication of materials. Related materials—such as charters, meeting summaries, and final deliverables—will be made public, and all final documents will be available under an open license.
    • Performance and integrity monitoring: Oversee the reliability, availability, and accuracy of the IIR service, including mechanisms for monitoring service performance and user feedback.
    • Security and privacy compliance: Ensure adherence to Credential Engine’s data governance, privacy, and information security standards.
    • Transparency and accountability: Publish updates to governance policies, report on operational performance, and maintain open communication with stakeholders regarding decisions or planned changes.

2.3.2 IIR Advisory Group’s Role

• • • Advisory support: Provide non-binding recommendations to Credential Engine Leadership on governance policies, verification processes, and interoperability considerations.
    • Stakeholder representation: Serve as a conduit for input from credential issuers, verifiers, and ecosystem partners to inform policy and operational decisions.
    • Technical and strategic alignment: Advise on alignment of IIR governance with verifiable credential standards, decentralized identity frameworks, and related technologies.
    • Collaboration and outreach: Support Credential Engine’s efforts to engage the broader community, communicate updates, and promote awareness of the IIR service.

2.4 Dispute Resolution Mechanisms

Credential Engine maintains responsibility for resolving any disputes, concerns, or challenges related to the governance, inclusion, or operation of the IIR service. The dispute resolution process is designed to ensure fairness, transparency, and consistency with Credential Engine’s governance policies and public-benefit mission.

2.4.1 Disputes may include, but are not limited to:

• • • Requests for review of eligibility determinations, verification outcomes, or decisions to deny inclusion in the IIR service.
    • Questions or challenges regarding eligibility, verification, or inclusion decisions.
    • Concerns related to policy interpretation, governance procedures, or data accuracy.
    • Reported inconsistencies, errors, or conflicts in issuer information.

2.4.2 Resolution process

• • • Submission: Any organization or stakeholder may submit a written request for review of a decision or policy matter related to the IIR service.
    • Acknowledgment and review: Credential Engine staff will acknowledge receipt and conduct an initial review to determine whether the issue can be resolved administratively or requires escalation.
    • Advisory notification: A sub-group of the IIR Advisory Group may be informed of relevant disputes for contextual understanding or may be asked to provide non-binding input when appropriate, particularly when matters inform future policy improvements.
    • Escalation: When necessary, the matter may be referred to Credential Engine’s executive leadership for formal consideration and decision.
    • Decision: Credential Engine retains ultimate responsibility and authority for all dispute resolutions. Final decisions will be documented.
    • Continuous improvement: While individual dispute details are not made public, outcomes that identify opportunities to strengthen IIR service governance, communications, or technology may inform future updates or revisions to IIR-related policies and procedures.

This process ensures that disputes are addressed fairly and consistently while preserving confidentiality, reinforcing accountability, and promoting continuous improvement across IIR service operations.

2.5 Communication and Reporting

Credential Engine maintains dedicated communication channels to ensure timely and consistent updates regarding Issuer Identity Registry (IIR) operations, governance, and participation. These communications support transparency, accountability, and collaboration with all stakeholders.

2.5.1 Communication Objectives

• • • Inform credential issuers, verifiers, and partners about IIR service updates, governance changes, and technical improvements.
    • Provide clear guidance on participation processes, verification criteria, and policy updates.
    • Support two-way communication to gather feedback and address stakeholder questions or concerns.

2.5.2 Communication Channels

• • • Email contact: Stakeholders may contact the IIR service team at iirservice@credentialengine.org for questions, feedback, or support related to IIR participation, governance, or technical integration.
    • Credential Engine website and newsletters: Major announcements, policy updates, and governance documents related to the IIR service will be made available through Credential Engine’s official websites and online newsletters.
    • Advisory and stakeholder engagement: Credential Engine may use established advisory groups, public webinars, or consultation sessions to share information and gather input on governance or technical developments.
    • Credential Registry system communications: Notifications may be issued through the Credential Registry publishing system to inform issuers or administrators about IIR-related actions or updates.
    • Social media: Official Credential Engine social media channels, such as LinkedIn, may be used to share updates, announcements, and engagement opportunities related to the IIR service.

2.6 Reporting and Transparency

Credential Engine upholds a strong commitment to transparency in the governance and operation of the Issuer Identity Registry (IIR) service. Key governance documents, procedures, and updates are made publicly accessible to ensure accountability and maintain stakeholder trust.

2.6.1 Transparency Principles

• • • All governance and operational materials will be openly licensed when possible, consistent with Credential Engine’s open data and public-benefit mission.
    • Credential Engine will ensure that published materials are accessible through official communication channels, including the Credential Engine website.

2.6.2 Reporting Responsibilities

• • • Publish IIR-related governance policies, verification criteria, and procedural documentation.
    • Provide updates when policies or governance materials are revised or replaced.
    • Maintain a public record of the IIR Advisory Group’s charter, membership, and outputs, consistent with Credential Engine’s open governance practices.

2.7 Continuity and Transition Planning

Credential Engine maintains documented measures to ensure the continuity and reliability of the Issuer Identity Registry (IIR) service in the event of organizational changes, system transitions, or unplanned disruptions. These measures safeguard service availability, data integrity, and long-term access to verified issuer information.

2.7.1 Continuity Objectives

• • • Maintain uninterrupted access to the IIR service and related verification functions.
    • Ensure preservation of IIR data integrity and records in the event of a transition.
    • Provide timely and transparent communication to stakeholders regarding material operational changes.

2.7.2 Continuity Planning Measures

• • • Business continuity and disaster recovery planning: The IIR service is included within Credential Engine’s broader business continuity and disaster recovery plan. These processes establish protocols for maintaining system operations, data protection, and service recovery in the event of disruptions or emergencies.
    • Transition management: In the event of an organizational change, system migration, or change in hosting arrangements, Credential Engine will implement documented procedures for transferring operational responsibility while maintaining data security and accessibility.
    • Stakeholder notification: Credential Engine will provide reasonable advance notice to IIR participants and stakeholders of planned transitions, and prompt notification of any unplanned events affecting service continuity.
    • Data stewardship: Should the IIR service be discontinued or transferred, Credential Engine will ensure that all verified issuer data are preserved, archived, or transferred to a designated successor steward, consistent with applicable governance and privacy policies. Note: A process for identifying a qualified successor organization and defining the procedures for securely transferring IIR data will be explored.
    • Open-source code and documentation: The IIR service codebase and related technical documentation will be maintained in Credential Engine’s public GitHub repository under an open license. This ensures continued transparency, accessibility, and the ability for future stewards to sustain or build upon the IIR service infrastructure.

These provisions ensure that the IIR service remains stable, transparent, and resilient, supporting the long-term trust and reliability necessary for global credential verification ecosystems.

3. Issuer Information and Verification

This section defines the processes and requirements for onboarding, verifying, and maintaining issuer identity records within the IIR service. All participating organizations must comply with the governance, verification, and maintenance criteria described below to remain in good standing.

3.1 Process for Initial Issuer Data Submission

Organizations seeking inclusion in the IIR service must complete the Credential Engine Issuer Registry application form, which will be integrated with the Credential Registry publishing system. The form will collect data required to establish verified issuer identity and to populate related organization records in both the IIR service and the Credential Registry.

3.1.1 Issuer Information

To be included in the IIR service, issuer identity information is submitted through the Credential Registry publishing system using an integrated onboarding process. Submissions may be made either by individual organizations seeking inclusion in the IIR, or by trusted third-party publishers submitting issuer information in bulk on behalf of multiple organizations.

Trusted third-party publishers may include government entities, system operators, or other authoritative bodies with responsibility for maintaining official records of credential offerers or issuers within a jurisdiction or system. In such cases, some or all verification steps may have already been completed by the trusted third party in accordance with its mandate and governance framework. Credential Engine evaluates third-party submissions to determine the extent to which existing verification evidence may be relied upon or supplemented.

The IIR onboarding process supports two related but distinct functions:

• • • Issuer identity verification, resulting in inclusion in the IIR service as a verified issuer; and
    • Organizational description, resulting in a published organization record in the Credential Registry identified by a Credential Transparency Identifier (CTID).

The onboarding process collects the information necessary to substantiate issuer identity, establish cryptographic verification through a Decentralized Identifier (DID), and link the verified issuer to its corresponding organization record in the Credential Registry.

The verification requirements, evidence types, and evaluation criteria used during onboarding and periodic reviews are maintained separately in publicly available operational documentation. This governance framework defines what information is collected and how it is used, while the operational verification guidance defines how verification is performed and adapted across different onboarding contexts.

3.1.2 Issuer Information Collected (Overview)

The following table summarizes the categories of information collected during issuer onboarding and indicates how each is used within Credential Engine systems.

Information Collected	Purpose	Administrative Use (Internal Only)	IIR Record (Public Information)	Credential Registry (Public Information)
Legal organization name	Establishes authoritative organizational identity		✔	✔
Commonly used organization name	Supports recognition and public-facing display		✔	✔
Organization description	Provides contextual information about the issuer			✔
Authorized organizational contact(s) (name, title, email)	Supports verification, approvals, and communications (not public)	✔
Organizational type(s)	Classifies issuer role within credential ecosystems			✔
Organizational sector (public, private nonprofit, private for-profit)	Supports governance, reporting, and analytics			✔
Physical or registered address	Substantiates organizational existence and jurisdiction			✔
Official web domain(s)	Supports identity substantiation and domain control		✔	✔
Decentralized Identifier (DID)	Cryptographic issuer identifier used in credential proofs		✔
Credential Transparency Identifier (CTID)	Links issuer verification to descriptive organization data		✔	✔
Organizational identifiers (e.g., government registration numbers, IPEDS, accreditor IDs, D-U-N-S)	Supports identity substantiation and cross-system alignment	✔		✔
Evidence of credential issuance activity	Confirms issuer role and scope	✔
Evidence of authorization to operate (when applicable)	Confirms jurisdictional approval for regulated credentials	✔
Third-party quality assurance or authorization bodies	Provides additional context and verification signals			✔
Logo URL	Supports recognition and display		✔	✔

3.1.3 DID Submission and Validation

Each participating organization must provide a valid Decentralized Identifier (DID) as part of its IIR application. The DID must:

• • • Comply with a recognized DID method supported by the IIR (e.g., did:web, did:key, or other approved W3C-compliant methods).
    • Resolve to a DID document containing the organization’s public key(s) and required metadata.
    • Be verifiable as under the control of the submitting organization (via web-domain resolution, DNS verification, or equivalent proof of control).

Credential Engine will confirm DID validity as part of the verification process and link the verified DID to the organization’s CTID and Credential Registry record.

3.1.4 Submission Review

Submitted applications will be reviewed by the Credential Engine team before approval. Incomplete or unverifiable submissions may be returned to the applicant for clarification or resubmission.

3.2 Process for Verifying Issuer Identity and Legitimacy

Credential Engine is responsible for verifying the legitimacy and identity of each organization before inclusion in the IIR service. Verification ensures that only authentic organizations, accurately represented and operating within the scope defined by the IIR governance framework, are listed as participants.

3.2.1 Verification Process

• • • Authorized representative confirmation: Validate that the contact person submitting the application has the authority to represent the organization in credential issuance matters.
    • Initial screening: Confirm that the issuing organization is a legally recognized entity or a sub-unit of a legally recognized entity with valid identifiers and an operational web presence corresponding to the submitted data.
    • Credential validation: Confirm that the organization demonstrably issues learning, employment, or professional credentials to people, as defined within the CTDL framework.
    • Identifier verification: Validate the DID and identifiers such as the DUNS number (U.S.) or equivalent global identifier through authoritative or public business registries.

3.2.2 Verification Approach

• • • Hybrid process: Credential Engine will initially use a hybrid approach combining automated and manual verification. Manual review will be conducted by the Credential Engine team, supplemented by document checks, online research, or outreach to confirm authenticity.
    • Future automation: Credential Engine will explore opportunities to implement cost-effective and reliable API integrations (e.g., business registry data sources) to automate parts of the verification process over time.
    • Documentation and recordkeeping: Verification results and evidence will be documented and maintained as part of the organization’s IIR record.

Organizations that successfully complete verification will be approved for inclusion in the IIR service.

3.3 Process for Reviewing and Maintaining Issuer Information

Ongoing accuracy of issuer records is required to retain verified status in the IIR service. Credential Engine conducts periodic and event-driven reviews and requires issuers to keep records current.

3.3.1 Review Cadence

• • • Annual confirmation: Issuers must confirm or update organizational details, identifiers, and credential-issuance status at least once every 12 months. Organizations will receive a notification via email to confirm their information.
    • Interim checks: Credential Engine may perform interim checks to validate currency of data.
    • Comprehensive re-verification: Conducted at least every 24 months to re-verify data.

3.3.2 Triggers for Out-of-Cycle Review

• • • Legal name change or merger/acquisition.
    • Domain or authoritative website change.
    • Identifier change (e.g., DUNS or non-U.S. equivalent) or new identifier assignment.
    • Security events impacting issuer identity integrity (e.g., domain hijack, public key compromise).
    • Substantiated reports of inaccurate or misleading issuer claims.

3.3.3 Update and Confirmation Process

To ensure the continued accuracy and integrity of issuer records, participating organizations are required to notify Credential Engine of any material changes and to periodically confirm the validity of their information. Updates may include changes to legal identity, operational status, or contact information.

Credential Engine will validate submitted updates and may conduct additional verification as needed. Routine administrative changes are normally processed within ten business days, while complex updates requiring re-verification may take longer.

Re-verification confirms that the organization continues to meet the IIR service’s inclusion criteria and that all associated identifiers and credentials remain valid. This process includes:

• • • Legal entity and identifier confirmation: Ensuring that the organization remains a legally recognized entity with active and accurate identifiers.
    • Domain and communication verification: Confirming that official domains, web presence, and contact channels are current and under organizational control.
    • Credential issuance confirmation: Verifying that the organization continues to issue learning- or work-related credentials within the CTDL scope.
    • Technical credential verification: When applicable, confirming that Decentralized Identifiers (DIDs) and related cryptographic materials remain valid and uncompromised.

3.3.4 Statuses

The IIR service assigns public statuses to each organization at stages of the verification lifecycle, from initial application through participation in the IIR service. Statuses are used to distinguish internal administrative handling, public verification status, and public organizational record status.

Internal Credential Engine Record Statuses:

• Pending: The organization has submitted a request for inclusion, and identity verification is in progress. No verification decision has yet been made.
• Declined:  The organization’s request for inclusion in the IIR service was reviewed and not approved based on eligibility, verification, or scope criteria. This status is retained internally for audit and dispute resolution purposes.
• Withdrawn:  The organization has voluntarily withdrawn from participation in the IIR service. The organization’s public IIR record has been retained, consistent with Credential Engine’s data retention policies.  The user will not receive data currency notifications and their account is disabled. 
• Revoked: The  organization no longer meets inclusion criteria, has provided unverifiable or inaccurate information, or fails to remediate material issues after notice. Revocation follows Credential Engine’s dispute-resolution policy.  This means the DID is not included with or is removed from  the IIR.   If a record of a QA action was published to the Credential Registry it is updated to a revoked status. 

Public Facing IIR Statuses:

• Registered: The organization’s identity has been verified and DID has been validated and approved for inclusion in the IIR service.  A record of registering the organization’s DIDs is published by Credential Engine to the Credential Registry.  The public facing record is available in the Credential Registry.

3.3.5 Notifications

• • • Credential Engine provides written notice of required actions, deadlines, and potential status changes to the designated issuer contact via emailed notifications.
    • System notifications may also be issued through the Credential Registry publishing environment.

3.3.6 Record Hygiene and Archival

• • • Superseded records and verification artifacts are retained for auditability.
    • Public views expose only current, active issuer data; archival details are not publicly displayed.

3.3.7 Trust and Reputation Policy

The IIR service is designed to establish trust through verified organizational identity and factual evidence, not subjective opinions or reputational scoring. Its role is to provide reliable, machine-readable confirmation that an issuer meets established verification requirements.

This policy ensures the IIR service remains neutral, objective, and evidence-driven, supporting transparent verification without introducing subjective or reputational bias.

3.4 Key Management and Compromise Policy

Decentralized Identifiers (DIDs) are required for all organizations included in the Issuer Identity Registry (IIR) service. To preserve the security, integrity, and reliability of issuer identity records, Credential Engine establishes policies governing how cryptographic keys associated with issuer DIDs are registered, updated, verified, and managed within the IIR service, including in cases of planned key changes or suspected compromise.

3.4.1 Planned Key Rotation

Issuers are responsible for managing the cryptographic keys associated with their DIDs in accordance with their own security policies and practices. When an issuer plans to rotate, replace, or update keys associated with its DID, coordination with Credential Engine is required to ensure continuity of verification within the IIR service.

• • • Credential Engine will verify and store current public keys associated with each issuer’s DID record.
    • Issuers are required to notify Credential Engine in advance of any planned key rotation, providing the effective date and replacement key material.
    • Credential Engine will verify key ownership and linkage before updating the issuer’s verified DID record.
    • Updated key information will be documented in the IIR service and associated with the corresponding Credential Registry organization record.

Planned key changes do not invalidate credentials previously issued using prior keys, provided those keys remain resolvable for verification purposes.

3.4.2 Emergency Key Compromise Response

In the event of a key compromise or suspected misuse, Credential Engine will take immediate action to safeguard the IIR service and its participants.

• • • The issuer must promptly report the incident to Credential Engine using the designated IIR service email contact or the Credential Registry system.
    • Credential Engine will suspend the affected DID and flag the issuer’s record as “Security Review” pending investigation.
    • Replacement key material must be submitted and verified before the issuer’s “Verified” status can be reinstated.
    • All actions, findings, and resolutions will be recorded as part of the IIR’s audit and incident response log.

3.4.3 Notification and Audit

Credential Engine will:

• • • Maintain a secure record of all key events, including rotations, compromises, and revocations.
    • Conduct periodic reviews of DID key management practices as part of standard security and governance audits.
    • Notify affected issuers and stakeholders through the Credential Registry system and via email communications consistent with Credential Engine’s established notification procedures.

These requirements ensure cryptographic integrity, verifiable control, and ongoing trust in all issuer identity records maintained within the IIR service.

3.5 Policies for Organizations that Close, Merge, or Leave the IIR Service

Credential Engine maintains procedures to ensure continuity, transparency, and integrity of issuer data when participating organizations close, merge, or voluntarily leave the Issuer Identity Registry (IIR) service. These procedures are designed to preserve verifiable records and maintain accurate historical representation of issuer participation.

3.5.1 Organizational Closure

• • • Credential Engine will verify closure through authoritative sources or official documentation.
    • The organization’s record will remain in the IIR service as a verified entity, ensuring the continued validity of credentials previously issued.
    • The Credential Registry record will be marked with an operational CTDL Life Cycle Status “Ceased.”
    • The issuer’s IIR entry will remain visible for verification.
    • Credential Engine will maintain the record indefinitely for historical and verification purposes, consistent with data retention and archival policies.

3.5.2 Organizational Merger or Acquisition

If an organization merges with or is acquired by another entity, updates may be required to both the Issuer Identity Registry (IIR) and the Credential Registry to accurately reflect organizational identity, verification status, and lineage. Both the superseded and successor records can remain accessible to support long-term verifiability of previously issued credentials and transparent organizational lineage.

• • • The acquiring or resulting organization must submit a complete new verification form and undergo all standard verification checks required for inclusion in the IIR service.
    • Credential Engine will follow the issuer identity verification process described above to verify the acquiring or resulting organization and assign the appropriate IIR verification and organizational statuses.

Credential Registry Data: The issuer or Credential Engine may update the organization’s records to reflect the merger or acquisition.

• • • The historical issuer record is to be retained and marked as CTDL Life Cycle Status “Ceased”, while the successor organization will be linked using ceterms:supercededBy.
    • The successor organization’s record will include a reciprocal ceterms:supercedes property to reference the prior organization.

3.5.3 Voluntary Exit

If an organization chooses to withdraw from participation in the IIR service, the following process applies:

• • • A formal written notice must be submitted by an authorized representative via email to Credential Engine via iirservice@credentialengine.org or through a designated online IIR service form.
    • Credential Engine will confirm the request and update the organization’s internal record to a “Withdrawn” status.
    • The organization’s record will be removed from the public IIR service, and its Decentralized Identifier (DID) will no longer be discoverable or resolvable through IIR endpoints.
    • The record will be retained internally for audit and accountability purposes, consistent with Credential Engine’s data retention and archival policies.

3.5.4 Good-Faith Policies for Payment Defaults or Non-Renewal

Credential Engine maintains good-faith policies to address payment defaults or non-renewal in a manner that is fair, transparent, and consistent with its public-benefit mission and IIR governance framework.

Participation in the IIR service may be supported through an Open Model, Cost-Recovery Model, or Value-Added Services Model, as described in Section 1.4. When fees associated with cost recovery or value-added services apply, the following payment terms apply:

• • • Payment requirements and invoicing for services rendered.
    • If payment is not received within a specified period, Credential Engine reserves the right to charge late fees, suspend or discontinue IIR services for the organization, including suspension of verification activities and, where applicable, removal of the organization’s public IIR record.
    • Credential Engine will make reasonable efforts to notify organizations of overdue payments and provide an opportunity to resolve payment issues in good faith prior to taking any enforcement action.

3.5.5 Policies for Issuer Removal

Issuer removal from the IIR service may occur either through voluntary withdrawal (as outlined in Section 3.5.3) or through Credential Engine–initiated action resulting from non-compliance with IIR service requirements.

Removal for non-compliance: Credential Engine may remove an issuer from the IIR service when one or more of the following conditions apply:

• • • The organization no longer meets the inclusion, eligibility, or verification criteria established for the IIR service.
    • Required verification, re-verification, or confirmation activities are repeatedly unmet after reasonable notice.
    • Material misrepresentation, falsified information, or sustained inaccuracy is confirmed through review.
    • The organization fails to comply with applicable IIR governance policies, participation requirements, or related obligations.

Removal Process:

• • • Credential Engine will provide a written notice of the issue, which may be delivered via email, outlining the basis for removal and steps required for remediation.
    • A defined response period will be provided to allow the organization to clarify, correct, or dispute the issue in accordance with Credential Engine’s dispute-resolution procedures (see Section 2.4).
    • If remediation is not completed within the response period, Credential Engine will proceed with removal and update the organization’s internal Credential Engine record status to “Revoked.”
    • Revoked records will be removed from the IIR service but are retained internally for accountability and audit purposes, consistent with IIR retention and archival policies.

Post-removal: Organizations removed from the IIR service for non-compliance may reapply for inclusion once all applicable issues have been addressed. Any reapplication will be subject to the standard onboarding and issuer identity verification process in effect at the time of reapplication.

3.6 Documentation for Issuers

Credential Engine provides clear documentation and guidance to support organizations participating in the IIR service. These materials ensure that issuers understand verification requirements, operational procedures, and best practices for maintaining their verified status.

Guidance is publicly available through https://guidance.credentialengine.org/, which serves as the central resource for all Credential Engine publishing and participation documentation.

The IIR Handbook is also available from Credential Engine’s technical site https://credreg.net/issueridentityregistry

3.7 Issuer Support Contact

Credential Engine provides dedicated support for organizations participating in the IIR service. Issuers may contact the IIR service team for assistance with verification, updates, or questions related to participation. Support contact:

• • • Email: iirservice@credentialengine.org
    • Availability: Inquiries are reviewed and responded to during normal U.S. business hours.

Credential Engine also uses system notifications and the Credential Registry publishing environment to communicate directly with issuer contacts regarding verification, updates, or required actions.

4. Privacy Policy and Terms of Use

This section establishes the privacy, data protection, and usage policies governing participation in and use of the Issuer Identity Registry (IIR) service. It defines the rights and responsibilities of Credential Engine and participating organizations in protecting data, ensuring lawful and ethical use, and maintaining transparency consistent with Credential Engine’s public-benefit mission.

4.1 Reference to Credential Engine’s Privacy Policy

The Issuer Identity Registry (IIR) service operates under Credential Engine’s organizational Privacy Policy: https://credentialengine.org/privacy-policy/.

This policy governs collection, use, retention, and disclosure of personal information across Credential Engine websites and systems, including the Credential Registry and the IIR service. No separate privacy policy applies to the IIR service. All privacy practices (e.g., data minimization, contact data handling, storage, and retention) follow Credential Engine’s published Privacy Policy.

4.2 IIR Service Terms of Use

The following terms apply specifically to participation in and use of the Issuer Identity Registry (IIR) service operated by Credential Engine. They complement—and will ultimately be incorporated into—Credential Engine’s organization-wide Terms of Use https://credentialengine.org/terms-of-use/.

4.2.1 Purpose and Scope

These Terms establish the rights and responsibilities of organizations that participate in, access, or use the IIR service and its associated verification, publishing, and data-access functions.

The IIR service exists solely to verify the identity and legitimacy of organizations that issue digital, verifiable credentials. Data are provided for issuer verification and interoperability; they are not intended for marketing, profiling, or unrelated secondary uses. The IIR provides open API access consistent with Credential Engine’s public-benefit mission, subject only to protective measures needed to ensure availability and integrity.

4.2.2 Acceptable Use

Participants and users of the IIR service agree to:

• Submit only accurate, current, and verifiable organizational information.
• Use IIR data exclusively for legitimate verification of credential-issuers, interoperability, or research purposes consistent with the public-benefit intent of the registry and for no other purpose.
• Ensure that administrative contact information and system credentials provided for verification or account management remain confidential and are used solely for authorized communication with Credential Engine.

4.2.3 Misuse of Data Policy

As an open-access service, the IIR does not restrict lawful, standards-conformant access. However, Credential Engine may implement proportionate protective measures (e.g., rate limiting, IP/network blocks, key revocation) to address abuse or preserve service availability.

Credential Engine reserves the right to restrict, suspend, or terminate access for misuse, misrepresentation, or violation of these Terms.

Prohibited actions include:

• • • Altering, re-publishing, or aggregating IIR data in a way that removes attribution, changes verified meaning, or misrepresents source authenticity.
    • Using IIR data to imply endorsement, create rankings, or assess reputation.
    • Employing IIR data for commercial, surveillance, or marketing purposes unrelated to verifying issuer legitimacy.
    • Generating automated traffic that disrupts or degrades API performance.
    • Collecting or attempting to expose non-public administrative or technical contact information.
    • Copying, aggregating, or storing IIR data for any purpose other than as permitted in 4.2.2, or using IRR data in ways that could mislead, misrepresent, or compromise issuer trust.

Response to misuse: As an open-access service, the IIR does not restrict legitimate access but may implement protective measures to ensure service continuity and trust. These may include:

• • • Rate limiting or IP blocking of traffic that is disruptive or abusive.
    • Public clarification or correction of misrepresented or inaccurate data use.
    • Notification of stakeholders where misuse could affect confidence or data integrity.

These policies maintain openness and accessibility while ensuring that IIR data continues to serve its intended verification purpose as a trusted, public-good infrastructure.

4.2.4 Accuracy and Updates

Participating organizations are responsible for maintaining the accuracy of their verified information and promptly reporting changes as described in Section 3. Credential Engine may periodically request confirmation or updated data to preserve accuracy and trust.

4.2.5 Intellectual Property and Licensing

The IIR service software, registry structure, and documentation are the property of Credential Engine and protected by applicable IP laws.

Public IIR data and documentation are released under open licenses designated by Credential Engine, with license notices published alongside the datasets and documentation.

Reuse must preserve attribution and provenance and must not alter meaning or present the data in a misleading way. Use of the IIR does not grant rights to Credential Engine trademarks, logos, or proprietary technologies.

4.2.6 Liability and Disclaimers

• • • Liability: Provisions to hold the issuer registry owner harmless from certain claims or misuse of the registry. (B I)

The IIR service and its data are provided “as is” and “as available.” Credential Engine makes no warranties (express or implied) regarding uninterrupted availability, accuracy of third-party source data, or fitness for a particular purpose. Use is at your own risk. To the maximum extent permitted by law, Credential Engine shall not be liable for any direct, indirect, incidental, consequential, special, or exemplary damages arising from use of—or inability to use—the IIR service or its data.

4.2.7 Indemnification

Users and participating organizations agree to indemnify and hold harmless Credential Engine, its officers, employees, and partners from any claims, losses, or liabilities arising from misuse of the IIR API or data, violation of these Terms, or infringement of third-party rights.

4.2.8 Modification of Terms

Credential Engine may amend these Terms to reflect updates in law, policy, or technology. Changes will be published on Credential Engine’s official website, and continued use of the IIR service constitutes acceptance of the revised Terms.

4.2.9 Governing Law and Contact

These Terms are governed by the laws of the United States and the District of Columbia.

• • • • Contact: iirservice@credentialengine.org
      • Response hours: Normal U.S. business hours.

5. Data Access and Download Format

This section describes how issuer identity data are accessed through the Credential Engine Issuer Identity Registry (IIR) service.

At this time, the IIR provides access only through machine-readable API endpoints that return cryptographically signed JSON Web Tokens (JWTs) containing verifiable issuer metadata. The IIR functions as a verification service, not a descriptive linked-data registry.

Unlike the Credential Registry—which publishes rich, descriptive data using the Credential Transparency Description Language (CTDL) and JSON-LD—the IIR provides only the minimal, cryptographically signed metadata necessary to establish issuer authenticity. Each IIR record includes a Credential Transparency Identifier (CTID) and reference to the corresponding Credential Registry organization record, enabling verifiers to confirm an issuer’s Decentralized Identifier (DID) and, when needed, retrieve additional information about the organization and its credentials from the Credential Registry.

5.1 Retrieval Methods: Machine-Readable

All retrieval from the IIR service occurs through RESTful API endpoints that return signed JWT responses. Each JWT is signed using the EdDSA algorithm to ensure authenticity, integrity, and non-repudiation. The returned metadata include identifiers and trust elements, not descriptive data expressed in CTDL or JSON-LD.

Access is currently machine-to-machine only; no human-readable interface is available. The IIR data are intended for automated verification by credential wallets, verifiers, and other systems that need to confirm issuer identity.

5.2 Public Access

The Issuer Identity Registry (IIR) service provides open, standards-based access to public issuer verification data. All verification endpoints are publicly accessible and designed for integration into verifiable credential ecosystems.

• • • • • Public Access: Verifiers may access public IIR verification data through the IIR’s public API endpoints, including trust anchor, issuer, and subordinate list endpoints. These endpoints return cryptographically signed, verifiable metadata that confirm issuer authenticity without exposing administrative, operational, or non-public issuer data.
        • Controlled Access: Access to IIR administrative and maintenance data is restricted through role-based controls.
          • Credential Engine staff have full access to IIR administrative and maintenance data required to perform issuer onboarding, identity verification, ongoing maintenance, governance enforcement, security monitoring, and audit activities.
          • Participating organizations have access only to their own IIR administrative data and issuer records for the purposes of submitting required information, responding to verification or re-verification requests, and maintaining the accuracy of their organization’s data. Participating organizations do not have access to administrative or maintenance data associated with other issuers.

5.3 Documentation for Users

Credential Engine provides comprehensive documentation and reference materials to assist verifiers, developers, and ecosystem partners in understanding and using Issuer Identity Registry (IIR) data. These resources ensure that both technical and non-technical audiences can effectively retrieve, verify, and integrate trusted issuer metadata.

Available documentation and resources:

• • • • • Guidance Site: General guidance, explanatory materials, and user-friendly participation information are available at https://guidance.credentialengine.org/.
        • Technical Site: Detailed technical specifications, integration guides, and schema documentation are maintained on Credential Engine’s Technical Site at https://credreg.net.
        • Swagger Interface: A live, interactive API reference and testing interface for the IIR endpoints is available at https://issuerregistry.credentialengine.org/swagger/index.html?urls.primaryName=OpenID+Federation.
        • GitHub Repository: The IIR source code, schema definitions, and supporting documentation are openly available under the Apache 2.0 license in Credential Engine’s public repository at https://github.com/CredentialEngine.

Documentation includes API endpoint descriptions, example requests and responses, data structure, schema, integration examples, and error-handling guidance.

5.3.1 User Support Contact

Users may contact the IIR service team via email for support, technical assistance, or to report issues related to registry access and data verification.

Email: iirservice@credentialengine.org

• Support requests are acknowledged and addressed during normal U.S. business hours.
• Credential Engine also issues system notifications and status updates through the Credential Registry publishing environment and communication channels including email.

6. Technical Standards

The Credential Engine Issuer Identity Registry (IIR) is built on open standards and cryptographic mechanisms that ensure global interoperability, verifiable trust, and integrity of issuer identity records.

The IIR uses both Decentralized Identifiers (DIDs) and Credential Transparency Identifiers (CTIDs) to uniquely and verifiably identify credential issuers and to link their IIR information with descriptive organizational data published in the Credential Registry.

6.1 Identifiers

The Credential Engine Issuer Identity Registry (IIR) uses a combination of globally unique identifiers to ensure verifiable trust, linkage, and interoperability across credential ecosystems. These are available to a verifier through the returned JSON Web Tokens from the IIR’s Open ID Federation endpoints.

• • • Decentralized Identifiers (DIDs): Each participating organization provides a DID, which functions as the cryptographically verifiable identifier for issuer identity and is validated and referenced through the IIR verification process. DIDs comply with the W3C DID Core Specification and may use the did:web method and did:key method. The DID provides the basis for cryptographic proof of control and issuer authenticity.
    • Credential Transparency Identifiers (CTIDs):  Each IIR record must also include a CTID that links the issuer’s verified trust metadata in the IIR to its corresponding organization record in the Credential Registry.  The CTID enables resolvable linkage to rich descriptive data, such as organization details and credential offerings, expressed in CTDL and JSON-LD within the Credential Registry.
    • Traditional URLs:  Non-verifiable but human-readable references such as homepage URLs, policy URLs, and logo URLs are included for informational context. These support user recognition as well as the IIR application process, but are not used for technical identity verification.

Together, the DID and CTID serve as the pair of authoritative identifiers for each issuer record in the IIR, combining cryptographic trust with linked open data integration.

6.2 Machine-Readable Credential Formats Supported

The Credential Engine Issuer Identity Registry (IIR) provides issuer metadata exclusively in machine-readable, cryptographically signed formats that support automated verification and interoperability with verifiable credential ecosystems.

• • • Format: All issuer metadata are returned as JSON Web Tokens (JWTs) encoded and signed using Secure Digital Signature Algorithms (DSA) such as the EdDSA (Ed25519) algorithm. Each JWT contains an authoritative, registry-verified set of issuer attributes, including DID, CTID, organization name, organization URL, logo URL, and Credential Registry URI, and can be independently validated by external verifiers.
    • Encoding and Signature: Metadata are structured in JSON and signed following JSON Web Signature (JWS) specifications to ensure integrity and non-repudiation. The signature can be validated against the Credential Engine trust-anchor public key published through the IIR API.
    • Format Limitations: The IIR does not issue, store, or verify individuals’ credentials. The IIR does not return data in CTDL or JSON-LD. It returns data about Issuers in JSON Web Token format as specified in the Open ID Federation specification. Data in CTDL formats are used within the Credential Registry, where CTIDs provide the linkage to descriptive credential and organizational data.
    • Interoperability: The JWT-based responses are compatible with verifier technologies that consume OpenID Federation 1.0 metadata, allowing verifiers to integrate the IIR into their trust-resolution workflows with minimal configuration.

This approach ensures that all data retrieved from the IIR are machine-verifiable, tamper-evident, and standardized for use across credentialing systems and federated trust networks.

6.3 Issuer Registry Standards Implemented

The Credential Engine Issuer Identity Registry (IIR) is implemented using a set of open, widely adopted, and interoperable technical standards. These standards collectively ensure that registry data are secure, verifiable, and compatible with emerging credential ecosystems—including those based on verifiable credentials (VCs) and decentralized identifiers (DIDs).

6.3.1 OpenID Federation 1.0

The OpenID Federation 1.0 specification serves as the core framework for establishing federated trust within the IIR. It provides standardized methods for publishing, retrieving, and verifying issuer metadata across interoperable registries.

The OpenID Federation 1.0 specification provides the foundational structure for federated trust within the IIR. It defines how entities publish, retrieve, and validate issuer metadata across interoperable systems.

At a broader level, the specification supports hierarchical trust chains, offline caching, and standardized governance models that enable cross-registry verification and scalable trust frameworks. These capabilities allow distinct registries or systems to interoperate securely while maintaining clear accountability for trust relationships.

Within Credential Engine’s IIR implementation, only the relevant portions of the specification are applied, specifically those that define metadata structures, entity statements, and API endpoints used for registry interoperability. The IIR focuses on verifiable metadata exchange and identity assurance through signed entity statements rather than implementing hierarchical or multi-registry trust structures at this stage.

Although OpenID Federation 1.0 uses URLs as entity identifiers and does not natively support DIDs, the specification is extensible, and Credential Engine’s implementation bridges traditional web-based trust models with decentralized identity systems by supporting both identifier types.

Most important parts of the specification implemented:

• • • §3 – Entity Statement
    • §5.1.1 – Federation Entity
    • §8 – Federation Endpoints

6.3.2 Decentralized Identifiers (DIDs)

The IIR requires all registered issuers to have a Decentralized Identifier (DID), providing a globally unique and cryptographically verifiable identity aligned with W3C Verifiable Credentials, Verifiable Credential Data Integrity, and Open Badges v3 ecosystems.

• • • A DID is a URI controlled by the issuer, enabling proof of ownership through cryptographic keys.
    • Supported DID methods include:
      • did:web – Encodes the DID as a resolvable URL (e.g., did:web:credentialengine.org), linked to a .well-known/did.json file containing public keys.
      • did:key – Embeds a public key directly within the DID string, allowing for immediate signature verification without external resolution.
    • DIDs are required for all organizations in the IIR and provide the cryptographic foundation for identity assurance and tamper-evident verification.

6.3.3 Credential Transparency Description Language (CTDL) and CTIDs

Each issuer record in the IIR includes a Credential Transparency Identifier (CTID) to link verified issuer identity data with the organization’s descriptive record in the Credential Registry.

• • • The CTDL (https://credreg.net/ctdl/handbook) is an open family of schemas maintained by Credential Engine for describing credentials, organizations, learning opportunities, skills, assessments, quality assurance relationships, jobs, and more.
    • CTIDs (https://credreg.net/ctdl/ctid) are globally unique, persistent identifiers based on UUID v4.
    • Although the IIR does not issue or return data in CTDL or JSON-LD formats, CTIDs provide the linkage between the IIR’s verification layer and the Credential Registry’s descriptive data layer, ensuring interoperability and consistency across ecosystems.

6.4 Cryptographic Signing Mechanisms

The Issuer Identity Registry (IIR) ensures the authenticity and integrity of issuer metadata through standardized cryptographic signing. All metadata responses distributed by the IIR service are signed by Credential Engine and can be independently verified by external applications. These cryptographic signing mechanisms ensure that issuer metadata is digitally verifiable, tamper-evident, and protected against unauthorized modification, supporting the trust and integrity objectives of the IIR service.

Together, these mechanisms constitute the IIR’s verification infrastructure, enabling verifiers to confirm that issuer metadata was verified by Credential Engine and has not been altered since publication.

Issuer cryptographic signatures are validated during onboarding and re-verification to confirm the issuer’s control of its Decentralized Identifier (DID). Only the IIR’s signature is included in metadata responses returned to verifiers.

Signing Method:

• • • All OpenID Federation metadata responses are signed using a supported DSA algorithm.
    • Responses are encoded as JSON Web Tokens (JWTs) that encapsulate both metadata and the digital signature.
    • Each JWT includes:
      • A header identifying the signing algorithm.
      • A payload containing verified issuer metadata.
      • A signature generated using Credential Engine’s private signing key.

Verification Process:

• • • Verifiers validate the JWT using the public key associated with the Credential Engine IIR’s Decentralized Identifier (DID).
    • Successful verification confirms that:
      • The data originated from the Credential Engine IIR.
      • The content has not been altered in transit.
    • If verification fails, the IIR returns a structured error response indicating invalid or unverified data.

6.5 Verifier Integration

The Issuer Identity Registry (IIR) provides an open, standards-based interface that allows verifiers, such as employers, credential evaluation services, and education or workforce systems, to confirm that a credential was issued by a verified organization. Integration is accomplished through direct API access using standard OpenID Federation 1.0 endpoints.

6.5.1 Integration Overview

Verifiers integrate with the IIR service by retrieving signed metadata through its public OpenID Federation API endpoints. Each response is a cryptographically signed JSON Web Token (JWT) that can be validated using the IIR’s public key. Successful verification confirms both the authenticity of the registry as the trust anchor and the integrity of the issuer data returned.

6.5.2 Available OpenID Federation Endpoints

• • • Trust Anchor Information – Provides metadata about the Credential Engine IIR as the registry host. GET /oidfed/.well-known/openid-federation
    • Issuer List – Returns a list of all registered issuer DIDs. GET /oidfed/federation_list
    • Issuer by DID – Returns a signed JWT containing the issuer’s verifiable metadata. GET /oidfed/federation_fetch?sub={did}

6.5.3 Integration Steps for Verifiers

• • • Retrieve the IIR public key from the trust-anchor endpoint.
    • Fetch the desired issuer metadata (by DID) using the federation_fetch endpoint.
    • Validate the returned JWT using the IIR’s public key to confirm origin and integrity.
    • Optionally, use the CTID included in the metadata to retrieve richer descriptive data about the same organization from the Credential Registry.

6.5.4 Documentation and Support

• • • Technical Documentation: Detailed API reference materials, including Swagger UI, are maintained on the Credential Engine Technical Site at https://credreg.net.
    • General Guidance: High-level participation, verification, and data-use information are available on Credential Engine’s Guidance Site at https://guidance.credentialengine.org.
    • Verifier Support Contact: Questions or requests for integration support may be directed to iirservice@credentialengine.org and are reviewed during normal U.S. business hours.

6.6 Storage of Records

The Issuer Identity Registry (IIR) ensures the integrity, authenticity, and verifiability of issuer metadata through cryptographic signing, validation, and secure infrastructure controls. Each record is cryptographically verifiable at the point of retrieval, and all metadata responses are tamper-evident and transparently verifiable by external applications. These measures allow verifiers to confirm that issuer data was provided by Credential Engine and has not been altered, without relying on blockchain or other third-party trust systems.

6.6.1 Tamper-Evident Design

• • • Each issuer’s registry record is returned as a cryptographically signed JSON Web Token (JWT) issued by Credential Engine as the operator of the IIR service.
    • The JWT is signed using Credential Engine’s private key, representing the IIR service’s trust anchor, and is associated with the IIR’s Decentralized Identifier (DID).
    • JWTs are signed using a Secure DSA (such as Edwards Curve Digital Signature Algorithm (EdDSA)).
    • Any modification to the signed JWT invalidates the signature, allowing verifiers to immediately detect tampering or unauthorized alteration.

6.6.2 Record Integrity and Validation

• • • Verifiers validate signatures using the IIR’s published public key.
    • Successful validation confirms that:
      • The data originated from the Credential Engine IIR trust anchor.
      • The content has not been changed since issuance.
    • If verification fails, the IIR returns a structured error response identifying the record as invalid or unverified.

6.6.3 Secure Storage and Infrastructure Controls

• • • Issuer metadata and associated verification artifacts are stored in Credential Engine’s secure, managed infrastructure, which includes containerized services deployed in a controlled cloud environment with auditable configurations.
    • Access to record maintenance endpoints is restricted to authorized Credential Engine personnel. Approved organizations in the IIR have access to only their organization’s information.
    • All record changes, key events, and verification actions are logged for traceability and security oversight.

7. Security and Operations

This section outlines the security controls, operational practices, and technical management procedures that ensure the reliability, availability, and integrity of the Issuer Identity Registry (IIR) service. These controls are designed to protect issuer identity data, sustain system performance, and maintain user trust in alignment with Credential Engine’s public-benefit mission and governance framework.

7.1 Security Controls and Data Protection Methods

Credential Engine employs layered security measures to safeguard the IIR’s systems, data, and cryptographic materials. These controls align with industry best practices for web-based trust infrastructure.

• Access Controls: Administrative access to the IIR’s infrastructure, codebase, and APIs is limited to authorized Credential Engine personnel and managed through secure authentication mechanisms.
• Infrastructure Security: The IIR operates within a secured cloud environment using containerized services (Azure Kubernetes Cluster) and PostgreSQL storage with controlled access policies, encryption at rest, and role-based privileges.
• Data Transmission Security: All communications between clients and the IIR endpoints occur over HTTPS using TLS encryption protocol.
• Cryptographic Integrity: Metadata responses are signed using a supported Secure Digital Signature Algorithm to ensure tamper-evident verification.
• Audit Logging: Key system and data events—including changes to issuer records, key rotations, and access attempts—are logged for traceability and audit purposes.
• Incident Response: In the event of a detected or suspected security incident, Credential Engine will initiate its established incident response process, including containment, analysis, remediation, and notification procedures.

7.2 Service Level Expectations

The Issuer Identity Registry (IIR) service is designed and operated as a continuously available, production-level service. Credential Engine is committed to maintaining a reliable, secure, and performant environment that supports uninterrupted access for verifiers and participating issuers.

7.2.1 Service Availability

• The IIR service is expected to be available at all times except during planned maintenance or scheduled updates.
• Planned maintenance windows are communicated through official Credential Engine channels and/or direct email notification to participating issuers.

7.2.2 Performance and Responsiveness

The service infrastructure is monitored to maintain consistent uptime and operational performance.

7.2.3 Service Communication

• System status updates and maintenance notifications are published through Credential Engine’s official website and other designated communication channels.
• Any unplanned service interruptions or incidents are handled in accordance with Credential Engine’s incident response and business continuity procedures (see Section 2.7).
• Credential Engine responds to technical or operational issues reported to iirservice@credentialengine.org during normal U.S. business hours.

7.3 Key Rotation and Compromise Policies

The Issuer Identity Registry (IIR) relies on cryptographic signatures to ensure that all issuer metadata retrieved by verifiers is authentic and tamper-evident. Key rotation policies described in this section apply specifically to Credential Engine’s registry-level signing keys used to sign metadata responses, while issuers independently manage their own keys through their Decentralized Identifiers (DIDs).

7.3.1 Registry Signing Keys

Credential Engine maintains secure cryptographic signing keys used by the Issuer Identity Registry (IIR) to sign issuer metadata responses. These registry-level keys establish the trust anchor for verifying IIR metadata and are distinct from issuer-managed keys associated with Decentralized Identifiers (DIDs).

Credential Engine manages the lifecycle of registry signing keys in accordance with established security practices. In the event of a suspected or confirmed key compromise, Credential Engine will revoke the affected key, issue a replacement, and take appropriate steps to preserve the integrity and trustworthiness of the IIR service.

7.3.2 Issuer Keys

• Purpose: Each issuer manages its own key pairs associated with its DID for signing verifiable credentials.
• Responsibility: Credential Engine does not store, issue, or manage issuer private keys. Issuers remain fully responsible for the maintenance, rotation, and security of their own DIDs and associated keys.
• Registry Updates: When issuers rotate their keys or update their DIDs, they must submit an updated IIR record to ensure verifiers have access to the newly added metadata.

7.4 IIR Open Source Code

The Issuer Identity Registry (IIR) service is developed and maintained by Credential Engine as an open-source project to promote transparency, trust, and shared innovation across verifiable credential ecosystems.

The IIR codebase is publicly available under the Apache 2.0 license within Credential Engine’s official GitHub repository at https://github.com/CredentialEngine. This license permits reuse, modification, and redistribution with appropriate attribution, ensuring that partners and developers can adopt or extend the IIR framework within their own trust ecosystems.

7.5 Production and Sandbox Environments

Credential Engine maintains separate environments for sandbox and production to ensure operational stability, data integrity, and controlled development. The sandbox environment supports internal development, integration testing, and partner experimentation prior to production deployment. Access to the sandbox environment must be requested and approved by Credential Engine to ensure appropriate use and system security.

The production environment provides the live, continuously available Issuer Identity Registry (IIR) service used by verifiers and participating issuers. Automated testing and monitoring processes are implemented to validate functionality, confirm security controls, and detect regressions prior to each release.