A proposal to have structured identification certificates

vips/VIP-243.md

@@ -0,0 +1,107 @@
+---
+VIP: 243
+Title: Extensible Certificate Payload Types
+Description: This VIP proposes to expand certificate payload types to include JSON and YAML formats with optional IPFS CID references.
+Author: Ignat Zapolsky <[email protected]>
+Category: Interface
+Status: Draft
+CreatedAt: 2025-01-09
+---
+
+## Overview
+
+This VIP proposes an extension to the certificate payload types defined in VIP-192. The extension aims to include JSON and YAML formats with optional Content Identifier (CID) references to JSON schemas stored on IPFS. This enhancement will provide more flexibility and standardization in certificate payloads while maintaining compatibility with existing implementations.
+
+## Motivation
+
+The current certificate payload structure, as defined in VIP-192, is limited in its ability to represent complex, structured data with schema validation. By expanding the payload types to include JSON and YAML formats with optional schema references, we can:
+
+1. Enhance data representation capabilities in certificates by allowing third parties to have native object rendering which is based on structured content type
+2. Allows extensibility and compactness of representation in the future by allowing more `types` 
+2. Provide future capability to define common semantics by providing reference schema documents
+2. Enable schema-based validation for improved data integrity
+3. Leverage IPFS for decentralized schema storage and retrieval
+4. Maintain backwards compatibility with existing implementations
+
+## Specification
+
+We propose to extend the `type` field in the certificate payload to include the following new values:
+
+1. `application/json+cid=<json schema cid on IPFS>`
+2. `application/yaml+cid=<json schema cid on IPFS>`
+
+The `+cid` part is optional, allowing for flexibility in schema usage.
+
+### Payload Structure
+
+The payload structure remains consistent with VIP-192:
+
+```json
+{
+  "type": "string",
+  "content": "string"
+}
+```
+
+### New Type Formats
+1. JSON format without schema:
+
+    ```json
+    {
+         "type": "application/json",
+         "content": "{\"key\": \"value\"}"
+    }
+    ```
+
+2. JSON format with schema:
+
+    ```json
+       {
+         "type": "application/json+cid=QmA1b2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0",
+         "content": "{\"key\": \"value\"}"
+       }
+    ```
+
+3. YAML format without schema:
+
+    ```json
+       {
+         "type": "application/yaml",
+         "content": "key: value"
+       }
+    ```
+4. YAML format with schema:
+
+    ```json
+       {
+         "type": "application/yaml+cid=QmA1b2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0",
+         "content": "key: value"
+       }
+    ```  
+
+When a CID is provided, the JSON schema referenced by the CID should be used to validate the content.
+The process for retrieving and applying the schema is left to the implementation.
+## Rationale
+
+This extension builds upon the existing certificate structure defined in VIP-192, adding support for more complex data structures and schema validation. 
+By adding schema capability interested parties (like wallets) are able to display user-friendly information about signed certificate structure.
+The use of IPFS for schema storage ensures decentralized access and immutability of schemas.
+## Backwards Compatibility
+This proposal is backwards compatible with existing implementations of VIP-192. Certificates using the current payload types will continue to function without modification.
+## Test Cases
+[To be added: Test cases demonstrating the use of new payload types and schema validation]
+## Security Considerations
+1. Schema Retrieval: Implementations must ensure secure retrieval of schemas from IPFS.
+2. Schema Validation: Proper error handling should be implemented for cases where schema validation fails.
+3. Schema: Parties that are parsing schema documents need to be aware of security context and use strict mechanisms to prevent attacks via insecure schema documents.
+3. Content Size: Implementations should consider imposing size limits on payload content to prevent potential DoS attacks.
+
+## Affected Parties
+
+This VIP affects libraries and clients that would like to generate & comprehend certificates, notably:
+1. Vechain SDK
+2. VeWorld wallet
+
+This VIP does not affect protocol because identification certificates are not intended for consumption by public / authority nodes.
+
+Copyright and related rights waived via <./LICENSE.md|CC0>.