# 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](https://openid.net/wg/fapi/)

**Join the Community:**\
OpenID Foundation [mailing lists](https://openid.net/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:**

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

**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**&#x20;

**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 ](https://www.iana.org/assignments/cwt/cwt.xhtml)with IANA (Internet Assigned Numbers Authority).<br>

**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](https://docs.mosip.io) | [Community working groups](https://mosip.atlassian.net/wiki/external/OWExMjBhYzQ3Mjk1NGZlOWExMWEzODA2YzVjYjExNmQ)

***