Credential Issuance

​

Product Overview

The Emerging platform’s Credential Issuance system provides a standardized way to create, issue, and verify digital credentials for all entities in your cookstove projects. Built on W3C Verifiable Credentials standards and integrated with the Impact Hub public blockchain network, this system enables:

• Tamper-Proof Attestations: Issue cryptographically secure credentials that cannot be forged or altered
• Privacy Preservation: Control what information is shared and with whom
• Offline Verification: Validate credentials without requiring continuous connectivity to the issuer
• Selective Disclosure: Share only the necessary information for a specific verification
• Revocation Management: Update or revoke credentials when information changes or is no longer valid

This documentation explains how cookstove project implementers can interact with the platform to issue and manage credentials for all project participants and assets.

​

User Personas

​

Use Cases / User Stories

​

Business Credential Issuance

As a Cookstove Project Implementer, I want to obtain a verified Business Credential so that I can establish my Organisation’s identity and authority within the platform.

• Acceptance Criteria:
  • Organisation receives a cryptographically signed Business Credential
  • Credential includes verified business information (name, registration number, etc.)
  • Credential is linked to the Organisation’s DID
  • Credential can be verified by third parties

​

Project Certification

As a Project Manager, I want to issue a Certified Project Document credential (such as a Mitigation Activity Design Document and Validation Report) for my cookstove project so that I can prove its legitimacy and compliance with standards.

• Acceptance Criteria:
  • Project receives a Certified Project Document credential
  • Credential includes project details, methodology, and compliance information
  • Credential is linked to the project’s DID
  • Credential can be presented to auditors and carbon credit buyers

​

Device Certification

As a Cookstove Manufacturer, I want to issue Certificates of Manufacture for cookstoves so that their authenticity and specifications can be verified.

• Acceptance Criteria:
  • Each device receives a Certificate of Manufacture credential
  • Credential includes device specifications, manufacturing date, independent lab testing results, and quality standards
  • Credential is linked to the device’s DID
  • Credential can be verified by project implementers and end users

​

Household Registration

As a Field Agent, I want to issue Household Credentials to participating households so that they can be uniquely identified and their participation verified.

• Acceptance Criteria:
  • Each household receives a Household Credential
  • Credential includes necessary household information, including eligibility criteria, without exposing PII on the blockchain
  • Credential is stored with end-to-end encryption in IXO Matrix data rooms
  • Credential can be selectively disclosed to authorized verifiers

​

Functional Requirements

​

Credential Types and Schemas

The Emerging platform supports various credential types based on standardized schemas from Protocol Domains. Each credential type has a specific purpose and set of attributes:

​

Business Credential

For cookstove project implementers and Organisations:

• Schema: did:ixo:protocol:[unique identifier]#business-credential
• Key Attributes:
  • Legal business name
  • Registration number
  • Jurisdiction
  • Business type
  • Authorized representatives
  • Verification status

​

Certified Project Document

For cookstove projects:

• Schema: did:ixo:protocol:[unique identifier]#project-credential
• Key Attributes:
  • Project name
  • Project location
  • Project Document (e.g. Mitigation Activity Design Document and Validation Report)
  • Start and end dates
  • Certification standards
  • Verification status

​

Certificate of Manufacture

For cookstove devices:

• Schema: did:ixo:protocol:[unique identifier]#device-certificate
• Key Attributes:
  • Manufacturer
  • Model number
  • Serial number
  • Manufacturing date
  • Technical specifications
  • Efficiency rating
  • Quality standards compliance

​

Household Credential

For participating households:

• Schema: did:ixo:protocol:[unique identifier]#household-credential
• Key Attributes:
  • Household identifier
  • Location (region/district)
  • Number of members
  • Previous cooking methods
  • Eligibility criteria
  • Enrollment date
  • Assigned devices

​

Customer Credential

For end customers:

• Schema: did:ixo:protocol:[unique identifier]#customer-credential
• Key Attributes:
  • Customer identifier
  • Household identifier
  • Service agreements
  • Payment information
  • Communication preferences

​

Agent Credential

For distribution agents:

• Schema: did:ixo:protocol:[unique identifier]#agent-credential
• Key Attributes:
  • Agent identifier
  • Role and responsibilities
  • Assigned region
  • Training certifications
  • Authorization level

​

Fuel Credential

For fuel sources:

• Schema: did:ixo:protocol:fuel-certificate
• Key Attributes:
  • Fuel type
  • Source/manufacturer
  • Production date
  • Batch number
  • Quality metrics
  • Sustainability certification

​

Protocol Domains

Protocol Domains provide standardized credential schemas and verification rules:

​

Available Protocol Domains:

• Clean Cooking Protocol: did:ixo:protocol:[unique identifier]#clean-cooking

  • Provides schemas for all cookstove-related credentials
  • Defines verification rules and compliance requirements
  • Establishes standard attributes for each credential type

• Carbon Credit Protocol: did:ixo:protocol:[unique identifier]#carbon-credit

  • Provides schemas for carbon credit issuance and verification
  • Defines methodologies for emissions calculations
  • Establishes requirements for credit certification

• Sustainable Development Protocol: did:ixo:protocol:[unique identifier]#sdg

  • Provides schemas for SDG impact measurement
  • Defines indicators for each sustainable development goal
  • Establishes reporting requirements for SDG contributions

​

Using Protocol Domains:

1. Navigate to the “Protocols” section in the platform dashboard
2. Browse available Protocol Domains
3. Select the appropriate protocol for your credential type
4. Review schema requirements and verification rules
5. Use the protocol’s schema when creating credentials

​

Claim Submission and Evaluation

Before a credential can be issued, a claim must be submitted and evaluated:

​

Claim Submission Process:

1. Navigate to the “Claims” section in the platform dashboard
2. Select “Submit New Claim”
3. Choose the claim type based on the desired credential
4. Complete the required claim information
5. Attach supporting documentation
6. Sign and submit the claim

​

Using the API:

For programmatic claim submission, use the msgSubmitClaim function:

{
  "claimId": "[Unique Claim Identifier]",
  "claimType": "[Claim Type]",
  "subjectDid": "did:ixo:entity:[subject-identifier]",
  "issuerDid": "did:ixo:entity:[issuer-identifier]",
  "content": {
    // Claim-specific content based on schema
  },
  "attachments": [
    {
      "id": "[Attachment ID]",
      "name": "Supporting Document",
      "contentType": "application/pdf",
      "data": "[Encrypted Data or IPFS Hash]"
    }
  ]
}

​

Claim Evaluation:

Claims are evaluated through a combination of automated verification by Evaluation Oracle services and human review:

1. Automated Verification:

   • Schema validation
   • Required field checks
   • Cross-reference with existing data
   • Cryptographic signature verification

2. Human Review (when required):

   • Verification of supporting documentation
   • Compliance with standards and regulations
   • Additional checks based on credential type

3. Evaluation Outcomes:

   • Approved: Claim is verified and credential can be issued
   • Rejected: Claim does not meet requirements
   • Pending: Additional information or verification needed
   • Disputed: Claim is valid but requires additional review

​

Credential Issuance

Once a claim is approved, a credential can be issued:

​

Issuance Process:

1. Navigate to the “Claims” section and find the approved claim
2. Select “Issue Credential”
3. Review the credential information
4. Sign the credential with the issuer’s private key
5. Issue the credential to the subject

​

Using the API:

For programmatic credential issuance, use the msgIssueCredential function:

{
  "credentialId": "[Unique Credential Identifier]",
  "credentialType": "[Credential Type]",
  "schemaId": "did:ixo:protocol:[schema-identifier]",
  "subjectDid": "did:ixo:entity:[subject-identifier]",
  "issuerDid": "did:ixo:entity:[issuer-identifier]",
  "issuanceDate": "2024-01-01T00:00:00Z",
  "expirationDate": "2025-01-01T00:00:00Z",
  "content": {
    // Credential-specific content based on schema
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-01-01T00:00:00Z",
    "verificationMethod": "did:ixo:entity:[issuer-identifier]#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "[Cryptographic Proof]"
  }
}

​

Success Response:

Upon successful issuance, you’ll receive a response similar to:

{
  "height": "123456",
  "txhash": "ABCDEF1234567890",
  "data": {
    "credentialId": "[Unique Credential Identifier]",
    "status": "Active"
  }
}

​

Privacy-Preserving Storage

Credentials containing personally identifiable information (PII) are stored with end-to-end encryption:

​

IXO Matrix Data Rooms:

• Secure, encrypted storage spaces for sensitive credential data
• Controlled by Domain Controllers (credential issuers and subjects)
• Data is never stored unencrypted on the blockchain
• Access is granted through cryptographic authorization
• Servers may be hosted in-country to comply with local data protection laws

​

Storage Process:

1. PII is identified in the credential content
2. This data is encrypted using the subject’s public key
3. Encrypted data is stored in the IXO Matrix data room
4. A reference to the encrypted data is included in the credential
5. The blockchain only stores a hash of the credential and its status

​

Access Control:

• Only authorized entities with the proper cryptographic keys can access the encrypted data
• The credential subject can grant or revoke access to specific verifiers
• Access can be time-limited or restricted to specific purposes

​

Credential Verification

Verification allows third parties to confirm the authenticity and validity of credentials:

​

Verification Methods:

• Direct Verification: Verifier directly checks the credential against the blockchain
• Intermediated Verification: Verification through a trusted third-party service
• Offline Verification: Verification without requiring internet connectivity

​

Verification Process:

1. Verifier requests a credential from the holder
2. Holder presents the credential (full or selective disclosure)
3. Verifier checks:
   • Issuer’s digital signature
   • Credential status on the blockchain (active, revoked, expired)
   • Schema compliance
   • Proof of subject control (holder proves they are the subject)

​

Using the API:

For programmatic verification, use the verifyCredential function:

{
  "credentialId": "[Unique Credential Identifier]",
  "presentationContext": "[Verification Context]",
  "verifierDid": "did:ixo:entity:[verifier-identifier]"
}

​

Credential Exchange

Credential exchange enables secure sharing of credentials between parties:

​

Exchange Methods:

• Direct Exchange: Peer-to-peer sharing between holder and verifier
• Mediated Exchange: Exchange through a trusted intermediary
• Selective Disclosure: Sharing only specific attributes from a credential

​

Exchange Process:

1. Verifier sends a credential request specifying required attributes
2. Holder reviews the request and consent requirements
3. Holder creates a Verifiable Presentation containing requested credentials
4. Holder sends the Verifiable Presentation to the verifier
5. Verifier validates the presentation and extracts the credential data

​

Verifiable Presentation

Verifiable Presentations allow credential holders to combine multiple credentials and selectively disclose information:

​

Presentation Creation:

1. Navigate to the “Credentials” section in the platform dashboard
2. Select “Create Presentation”
3. Choose the credentials to include
4. Select which attributes to disclose from each credential
5. Sign the presentation with the holder’s private key
6. Share the presentation with the verifier

​

Using the API:

For programmatic presentation creation, use the createVerifiablePresentation function:

{
  "presentationId": "[Unique Presentation Identifier]",
  "holderDid": "did:ixo:entity:[holder-identifier]",
  "credentials": [
    {
      "credentialId": "[Credential Identifier]",
      "disclosedAttributes": ["attribute1", "attribute2"]
    }
  ],
  "audience": "did:ixo:entity:[verifier-identifier]",
  "expirationDate": "2024-02-01T00:00:00Z"
}

​

Non-functional Requirements

​

Security

• All credentials must be cryptographically signed by the issuer
• Private keys must never be transmitted or stored unencrypted
• Credential exchange must use secure communication channels

​

Privacy

• PII must be stored with end-to-end encryption
• Selective disclosure must be supported for all credential types
• Data minimization principles must be followed

​

Interoperability

• Credentials must conform to W3C Verifiable Credentials Data Model
• Credentials must be compatible with major wallet applications
• The system must support standard cryptographic algorithms

​

Performance

• Credential issuance should complete within 30 seconds
• Verification should occur in under 5 seconds
• The system should handle high volumes of credential operations

​

Compliance

• The system must comply with relevant data protection regulations
• Credential issuance must follow industry standards and best practices

​

Assumptions & Constraints

​

Assumptions

• Issuers have the necessary authority to issue specific credential types
• Users have access to digital wallets for storing and presenting credentials
• Internet connectivity is available for credential issuance and verification
• Users understand the concept of consent for credential sharing

​

Constraints

• Some credential types may require specific issuer qualifications
• Offline verification may have limited capabilities compared to online verification
• Credential schemas must conform to protocol standards
• Revocation checking requires periodic synchronization with the blockchain

​

Appendices

​

Glossary of Terms

• Verifiable Credential: A tamper-evident credential with authorship that can be cryptographically verified
• Claim: An assertion made by an entity about a subject
• Credential Schema: A document that defines the structure and constraints of a credential
• Issuer: An entity that creates and signs credentials
• Holder: An entity that receives and stores credentials
• Verifier: An entity that checks the validity of credentials
• Selective Disclosure: The ability to reveal only specific information from a credential
• Verifiable Presentation: A tamper-evident presentation of one or more credentials

​

Related Documentation