# Standards, Specifications and Compliance
#### Standards Implemented in Certify
***
#### Overview
Inji Certify is the credential issuer module. It enables organizations to issue digitally signed, standards-compliant verifiable credentials at scale. Certify is the origination point for all credentials that flow through the Inji ecosystem.
**W3C Verifiable Credentials Data Model**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Credential Issuance**: Full support for both v1.1 and v2.0 credential structures
* **Proof Types**: JSON-LD Proofs, JWT, SD-JWT, planned Data Integrity 2.0
* **Automatic Versioning**: Can issue v1.1 credentials for legacy systems or v2.0 for modern deployments
* **Multi-Format Support**: Same credential content can be delivered in JSON-LD, JWT, or SD-JWT based on holder request
* **SVG Rendering Templates**: v2.0 credentials can include SVG-based display templates for visual rendering in wallets
* **Semantic Contexts**: Custom JSON-LD contexts for domain-specific vocabularies (e.g., educational credentials, health credentials)
* **Credential Status**: Includes revocation status endpoint referencing W3C Bitstring Status List
**Release Timeline**:
* v0.8.0+: W3C VC 1.1 support
* v0.11.0+: Full W3C VC 2.0 support
* Ongoing: Enhanced proof mechanisms, new credential types
***
**OAuth 2.0 & OpenID Connect**
**Specification**: , (See Standards Library for details)
**Certify-Specific Implementation**:
* **Authorization Code Flow**: Secure user login and credential issuance authorization
* **OIDC Integration**: eSignet integration for federated identity; supports Google OAuth, Keycloak, custom OIDC providers
* **Token Validation**: Issued access tokens validated against configured identity provider
* **Scope Management**: Fine-grained scopes for different credential types and issuance flows
* **Pre-Authorized Code Flow**: Direct issuance without full OIDC flow (speed for certain deployment scenarios)
* **User Binding**: Credentials bound to authenticated user identity
***
**OpenID4VCI (Verifiable Credential Issuance)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Credential Endpoint** (`/credential`): Responds to credential requests from wallet holders
* **Batch Issuance**: Issue multiple credentials in single request
* **Multiple Formats**: Issue JSON-LD, JWT, or SD-JWT based on holder capability and issuer policy
* **Credential Offer**: Generate shareable credential\_offer URIs that wallets can accept
* **Authorization Server Integration**: Pluggable authorization (eSignet, Keycloak, custom OAuth 2.0)
* **Deferred Issuance**: Support for issuance transactions that complete over time
* **Proof Validation**: Require holders to prove key possession during issuance
* **Response Metadata**: Provide issuance details (accepted algorithms, supported formats, etc.)
**Release Info**: Available since v0.8.0; enhanced with each release
***
**W3C DIDs (Decentralized Identifiers)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **DID Publishing**: Issuers publish their DID as credential issuer identifier
* **Key Publication**: DIDs resolve to public key material for signature verification
* **DID Methods Supported**: did:mosip, did:ion, did:key (method-specific implementations)
* **Credential Context**: All credentials include 'issuer' field with issuer DID
* **Key Rotation**: Support for DID key rotation while maintaining credential validation
* **Interoperability**: DIDs follow W3C DID specification for universal recognition
***
**JSON-LD (Linked Data)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Credential Context**: Custom JSON-LD contexts for domain-specific vocabularies
* **Semantic Mapping**: Map credential attributes to standard URIs (schema.org, FOAF, custom vocabularies)
* **Linked Data Processing**: Support for @context, @id, @type in credential structure
* **Extensibility**: Custom vocabularies without breaking interoperability
* **Human-Readable Output**: Credentials include human-friendly labels alongside URIs
***
**Selective Disclosure JWT (SD-JWT)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **SD-JWT Issuance**: Issue credentials with selectively-disclosable claims
* **Salt & Hash Structure**: Each claim salted and hashed for selective disclosure
* **Discloser Binding**: Support for listing which claims verifier may request
* **Claim Encryption**: Optional encryption of undisclosed claims
* **Fallback Disclosure**: Holder can disclose claims not explicitly requested (if issuer allows)
* **Release Timeline**: Drafts in v0.12.0, full support v0.13.0+
***
**W3C Bitstring Status List**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Status List Publishing**: Publish credential revocation status as bitstring
* **Credential Status Entry**: Credentials include reference to status list (list ID + position)
* **Revocation API**: Endpoint (`/revoke`) to revoke issued credentials
* **Bitstring Format**: Binary format with efficient indexing for 1M+ credentials
* **Privacy Preservation**: Bitstring doesn't reveal which specific credentials are revoked
* **Distribution**: Status list hosted and distributed by issuer
***
**CBOR (Concise Binary Object Representation)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Claim 169 Encoding**: Encode identity attributes in CBOR format for QR embedding
* **Compact Payload**: CBOR-encoded credentials 30-50% smaller than JSON
* **QR Size Optimization**: Compact encoding ensures QR codes remain scannable
* **Release Timeline**: Claim 169 support planned v0.14.0
***
**CWT/COSE (CBOR Web Token & Object Signing and Encryption)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **Claim 169 Signing**: Sign CBOR-encoded identity QR codes with CWT/COSE signatures
* **Ed25519 Signing**: Use Ed25519 algorithm for Claim 169 signatures (IANA-registered)
* **Signature Validation**: Digital signatures embedded in CBOR payload for offline verification
* **Release Timeline**: Planned v0.14.0 with Claim 169 support
***
**Claim 169: MOSIP QR Code Specification**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **QR Encoding**: Encode identity credentials as Claim 169-compliant CBOR-CWT QR codes
* **Attribute Support**: Support all 23 attributes (v1.2.0):
* Standard 18 identity attributes (name, DOB, nationality, address, etc.)
* Humanitarian focus: legal status, secondary language, location code
* **Signature Schema**: Ed25519 or ECC signatures for offline verification
* **QR Embedding**: Claim 169 QR can be embedded in W3C credentials as supplementary format
* **Multi-QR Support**: Single credential can contain multiple Claim 169 QRs (different use cases)
* **Release Timeline**: Planned v0.14.0
***
**JWT (JSON Web Token)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation**:
* **JWT-VC Issuance**: Issue credentials in JWT (not JSON-LD) format
* **Claims in JWT**: Credential structure mapped to JWT claims structure
* **Compact Distribution**: JWT smaller and faster than JSON-LD equivalent
* **Signature Algorithm Selection**: Support Ed25519, RSA, ECDSA signing algorithms
* **Token Expiration**: exp claim for credential lifetime management
***
**Cryptographic Algorithms (Signing)**
**Certify-Specific Implementation**:
| Algorithm | Version | Status | Use Case |
| --------- | --------- | -------------------- | --------------------------------------- |
| Ed25519 | 2018 Spec | Available | Modern, high-performance signing |
| Ed25519 | 2020 Spec | Available (v0.11.0+) | Enhanced key format, recommended |
| RSA | 2048-bit | Available | FIPS 140-2 compliance, legacy systems |
| RSA | 4096-bit | Available | High-security deployments |
| ECDSA | secp256k1 | Available (v0.11.0+) | OpenID ecosystem, blockchain-compatible |
| ECDSA | P-256 | Available (v0.11.0+) | NIST standard, high security |
| ECDSA | P-384 | Planned | Enhanced security variant |
***
**W3C Data Integrity 2.0 (Planned)**
**Specification**: (See Standards Library for details)
**Certify-Specific Implementation** (Planned v0.15.0+):
* **JWS-Based Proofs**: Migrate from JSON-LD Proofs to JWS-based Data Integrity proofs
* **Algorithm Support**: Ed25519, RSA, ECDSA with Data Integrity 2.0 format
* **Canonical JSON**: Canonicalized JSON-LD before signing (prevents tampering)
* **Backward Compatibility**: Continue issuing JSON-LD Proofs for legacy systems
***
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.inji.io/inji-certify/technical-overview/standards-specifications-and-compliance.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.