Registry Overview and Purpose
Defines the scope, objectives, and operational principles of an issuer registry
Purpose and scope of the registry
The Digital Credentials Consortium (DCC) Member Registry is a list of members and the decentralized identity(ies) that they use to digitally sign their W3C Verifiable Credentials (VCs) and those credentials aligned with VCs like Open Badges 3.0.
Verifiers of these digital credentials can seek information about the DCC members using the decentralized identifier (DID) located in the credential.
Subject matter focus of the registry: Limited to issuers, potentially specific types of issuers
The purpose of this registry is to store information about issuers who are or who have been members of the DCC and are or have issued Verifiable Credentials. I
The DCC is a consortium of post-secondary institutions who issue digital degrees, micro-credentials, certificates, and other education-related or work-related VCs.
Information about issuers, including their DID, is added by DCC Support Staff once membership is confirmed and their DID is authenticated.
Funding model and sources
This registry is funded with membership fees.
Business model and fee structure for issuers
The DCC hosts this registry as a service to its members.
Use/storage of private individuals’ data (storage of private data should ideally not occur, or should only occur on a minimum basis)
A contact email will be stored internally by the DCC (not publicly posted) in order to contact issuers.
Governing Parties and Oversight
Addresses the roles and responsibilities of the governing bodies and mechanisms for ensuring transparent and effective oversight of an issuer registry.
Organization: Organizational mission
The Digital Credentials Consortium’s mission is to advance the use and understanding of privacy-enhanced, portable, verifiable digital credentials in higher education through open source technology development and leadership, research and advocacy.
Governing body or advisory board structure: Composition and roles
The Digital Credentials Consortium (DCC) Member Registry is under the purview of the DCC Members by-laws. This registry will only contain DIDs and issuer identity information pertaining to DCC members. The DCC is operated under the Massachusetts Institute of Technology, which employs the DCC staff and serves as the administrative center for the Consortium.
Governing body or advisory board structure: Processes for decision-making and resolving disputes
The DCC Member Registry is managed by the DCC support staff. This includes:
- oversight of operations, policies, and procedures,
- periodic review of registry performance and standards,
- communication and transparency policies for governance decisions,
- protocols for handling conflicts or challenges related to registry governance,
- and regular updates to stakeholders on registry changes and improvements.
The DCC membership is governed by a Leadership Council which provides input on the strategic direction of the Consortium. Leadership Council members follow a set of bylaws set by collective agreement.
DCC membership offers two tiers, Member and Core Member. The fee for membership is respectively $5000.00 and $20,000.00 per year with a commitment to a three year contract.
Members can be included in DCC member registries, participate in working groups, meetings and events, and can vote to elect Leadership Council members.
Core Members are entitled to all Member benefits. Additionally, they can nominate a member for the Leadership Council and receive priority technical support from DCC developers. In order to be eligible for membership, prospects must represent a non-profit or state funded postsecondary education institution. Prospective members must submit a letter of interest for approval by the Leadership Council. Once approved, the institution will enter into an agreement with the Massachusetts Institute of Technology, which employs the DCC staff and serves as the administrative center for the Consortium.
Responsibilities of the governing parties: Oversight of operations, policies, procedures, and performance
The Director of the DCC is responsible for supervision and oversight.
Responsibilities of the governing parties: Communication and transparency policies for governance decisions
The DCC releases a report to its members on an annual basis and is accountable to the members. Oversight of the DCC is provided by the members.
Dispute resolution mechanisms: Protocols for handling conflicts or challenges related to registry governance
Dispute resolution will be handled by DCC Support Staff under the direction of the Director and if necessary, the DCC Leadership Council.
Communication and reporting: Channels for stakeholder engagement. This could include messaging about updates to the registry, requests for updates from the participants, updates about the organization hosting the registry, etc.
Contact emails and internal DCC member mailing lists will be used to communicate any major updates. Registry request updates should be directed to the DCC Support team at digitalcredentials@mit.edu.
Privacy Policy and Terms of Use
Establishes the legal and contractual rights and obligations of the issuer registry with respect to data providers and data users.
This section is still being developed.
Limitation of liability: Provisions to hold the issuer registry owner harmless from certain claims or misuse of the registry
TBD
Misuse of data: Policies and consequences for improper use of registry data.
TBD
Privacy and data protection requirements, including compliance with applicable laws
TBD - No private data is stored
Credential holder privacy protections (preventing “calling home”, etc.)
TBD
Registry access will be public but IP addresses, location, or other identifying information will not be logged.
Intellectual property and licensing considerations: Ownership and usage rights for registry content and data
TBD
Issuer Information and Verification
Details the processes and requirements for onboarding, verifying, and maintaining issuer records.
Process for initial issuer data submission: Mandatory and voluntary issuer information (Name, description, location, identifiers, credentials offered, contact information, etc).
Mandatory data (will be displayed publicly): DID (DID:web or DID:key), Organization name, Legal name, URL, Logo (1080 x 1080 px, square)
Mandatory data (will be used internally and not displayed publicly): Main contact point email
Optional: CTID, ROR
Process for verifying issuer identity and legitimacy: Know Your Customer (KYC) process/other identification process
Any communications will be confirmed by the issuer registry with the main contact point email. To join the registry, potential issuers must send a sample credential signed with their DID.
Process for verifying issuer identity and legitimacy: Use of third-party services (if any)
No third-party services used.
Process for reviewing and maintaining issuer information: Initial verification steps and estimated processing time
For an issuer to join, they contact the DCC with a letter of intent, agree to contract terms, and pay membership fees. . Entry reviews will occur on a rolling basis when an issuer requests to join the registry. The issuer must provide information as specified above. Processing time for new members is not measured.
Process for reviewing and maintaining issuer information: Frequency and criteria for periodic reviews and estimated processing time
The issuer registry will be updated on a rolling (as-needed) basis. If an issuer updates their information and sends it to the issuer registry maintainers, such change shall be shown in the registry within an estimated timeframe of 7 days. A yearly check will be conducted to confirm the accuracy of the issuer data (the registry maintainers will contact the issuer and confirm that the data is up-to-date). If any anomalies are found as a part of the yearly checks, the issuer will be required to update their data within 30 days. Otherwise, the issuer data can remain the same from year to year.
Trust and reputation policies: Defining trust levels or scales based on criteria met (e.g., evidence-based ratings)
Not implemented.
Trust and reputation policies: Addressing negative attestations or endorsements of issuers (e.g., “bad reviews”)
Not implemented.
Issuer planned/emergency key rotation and/or key compromise policies (including response, audit, and notification policies)
DID methods are used as identifying criteria. For DID:web type issuers, any changes in the signing key are the responsibility of the issuer. For DID:key type issuers, if an issuer changes their signing key voluntarily or involuntarily, the old DID:key will be removed from the registry. No notification will be provided or posted if issuers change their signing key and no audits will be performed.
Retention and archival policies: longevity of issuer data for long-term verification
There are no archival processes for issuers who participate in the registry. The registry is designed to operate in perpetuity; if the registry is shut down, efforts will be made to (a) first transfer the registry to another maintainer, and (b) if another suitable maintainer cannot be found, to archive the registry in a tamper-evident file format and host this file externally.
Policies for organizations that close, merge, or leave the registry
If an issuer leaves the registry or closes, their information will be removed. If an issuer is merged with another issuer, it will be the responsibility of those issuers to update their signing keys and other information.
Good-faith policies for payment defaults or non-renewal
If an issuer fails to make the required payments as a DCC member, they will have a period of 30 days to remedy payment delays. At the expiration of this period, the issuer may be removed from the issuer registry at the discretion of the support team.
Policies for issuer removal: Voluntary exit or non-compliance
If an issuer does not meet required criteria, the issuer will be required to update their data within 30 days. Issuers may also voluntarily remove themselves from the registry within this time period. At the expiration of this time period, issuers will be removed from the registry by the support team.
Documentation for issuers
Documentation is provided at https://github.com/digitalcredentials/dcc-members-oidf.
Issuer support contact
digitalcredentials@mit.edu
Data Download Format
Details the processes and policies regarding downloading issuer registry data.
Machine-readable and human-readable issuer registry retrieval methods
Information is not provided in a human-readable format.
Public vs. private registry access
Access to the registry is public.
Documentation for users
Documentation is provided at https://github.com/digitalcredentials/dcc-members-oidf.
User support contact
DCC support staff may be contacted at digitalcredentials@mit.edu
Technical Standards
Establishes the technical foundation for an issuer registry based on specific standards used.
DID URL/traditional URL/other identifiers used
Only DID urls may be used in this registry (DID:web or DID:key). It is recommended to use DID:web.
Machine-readable credential formats supported
N/A
Issuer registry standard/standards used
This registry uses a modified version of the OpenID Federation specification, draft 42 https://openid.net/specs/openid-federation-1_0.html. The modification entails the use of DIDs in addition to URL methods.
Cryptographic signing mechanisms: how external applications can confirm record integrity
Data integrity is preserved via the use of the HTTPS protocol when interacting with the registry contents. On an endpoint-level basis, integrity can also be checked for Entity Statements only by validating the JWT signature (no built-in integrity checks).
Verification infrastructure: Mechanisms for validating records against the issuer’s cryptographic signature
Issued credentials can be verified against the DID keys provided at the DID which is used as an identifier within the registry.
UPDATE Verification infrastructure: Mechanisms for validating records against the issuer registry’s cryptographic signature
The issuer registry signs all Entity Statements with a XXX key set.
Support for tamper-proof storage of records (e.g., append-only logs, blockchain)
None implemented.
Security and Operations
Describes cybersecurity and technical operations information regarding how the issuer registry code is operated and maintained.
UPDATE Security controls and data protection methods
The registry enforces TLS X.XXX on its endpoints according to the YYYY AWS best practice and ZZZZ. All code secrets are encrypted at rest.
Service Level Agreement (SLA) commitments
None implemented.
UPDATE Issuer registry planned/emergency key rotation and/or key compromise policies (including response, audit, and notification policies)
None implemented.
Open-source or closed-source code
Source code is open-source and is hosted on GitHub at https://github.com/digitalcredentials/dcc-members-oidf under the MIT license. To the extent possible, the code uses open-source libraries.
Existence of production and test environments and automated testing
The production environment is hosted at registry.dcconsortium.org, and the test environment is hosted at test.registry.dcconsortium.org. The test version of the repository is tested using the following automated tests, provided at [https://github.com/digitalcredentials/dcc-members-oidf/blob](https://github.com/digitalcredentials/dcc-members-oidf)
