Additional Complementary Standards

As part of committee discussions and ongoing technical review, several additional standards have been identified that complement and strengthen the ID interoperability standards adopted by DCI. These standards focus on security, identity, and claims representation, which are key for robust, interoperable digital social protection (SP) systems.

1. FAPI (Financial-grade API) Profile

Overview: The FAPI profile, developed by the OpenID Foundation, is a high-security API specification. It defines advanced security profiles for protecting APIs, including strong client authentication, secure token handling, and resistance to advanced attacks.

Why it matters for DCI:

• Enhances the security model for DCI APIs.

• Provides guidance on protecting sensitive registries and personal data.

• Supports implementation of strong OAuth2/OpenID Connect-based security flows.

Official Link: FAPI Specifications

Join the Community: OpenID Foundation mailing lists

2. NISP – National ID Security Profile

Overview: NISP extends FAPI 2.0 with citizen-first privacy rules tailored for government and national ID use cases. Currently under discussion between MOSIP and OpenID teams.

Key Privacy & Security Enhancements:

Feature	Benefit
Explicit consent per transaction	Users approve every data access request
Registered claims only	Clients cannot request unrestricted data
No PII in tokens	Personal data shared only via encrypted UserInfo
Pairwise pseudonymous IDs	National ID/phone/email never exposed directly
Short-lived tokens, no refresh	Limits window for credential compromise
Encrypted + signed UserInfo	End-to-end protection using client keys

Technical Foundation:

• RFC 7516 (JWE) – Encrypted UserInfo responses

• RFC 7523 (JWT assertions) – Client authentication without mTLS

• RFC 8446 (TLS 1.3) – Mandatory modern encryption

• OpenID Connect Identity Assurance 1.0 – KYC/verification support

Biometric Considerations: When biometric data is transmitted, it must be signed, encrypted, and bound to a transaction-specific nonce.

3. Claim 169 – QR Code Specification

Overview: Claim 169, a QR code specification is designed to drive interoperability in digital identity systems. The specifications development is led by MOSIP team and defines how to embed verifiable identity attributes in QR code using CBOR Web Tokens (CWT), enabling offline verification of identity with cryptographic trust. Claim 169 has been registered with IANA (Internet Assigned Numbers Authority).

Why This Matters:

• Offline verification in low-connectivity or rural areas

• Portable credentials for field enrollment and service delivery

• Cryptographic trust via issuer signature (no network required)

Data Structure: Identity attributes encoded in CBOR format (claim key 169):

• Core fields: ID, name components, DOB, gender, address

• Optional: email, phone, nationality, marital status, guardian info

• Biometrics: photo, fingerprint (with strict privacy controls)

Generation Process:

Prepare data → Structure as claim 169 → Generate CWT (COSE_Sign1) 
→ Compress (zlib) → Encode (Base45) → Create QR code

Security Model:

• Signature verification via published JWKs

• Optional payload encryption for sensitive use cases

• Careful PII handling with consent requirements

Resources: MOSIP Claim 169 Specification | Community working groups

---