v1.0.0 Draft•Last updated: January 2026

Road Safety Certification Protocol

An open standard for issuing, holding, and verifying road safety credentials for delivery riders and drivers worldwide.

1. Overview

1.1 Abstract

RSCP (Road Safety Certification Protocol) is a privacy-by-protocol standard for issuing, holding, and verifying road safety credentials. Unlike traditional credential systems that store personal data centrally, or pure zero-knowledge systems that sacrifice issuer visibility, RSCP achieves a novel balance:

Registry operators cannot access personal data by protocol design
Issuers retain full visibility of credentials they issue
Holders control disclosure through selective disclosure proofs

1.2 Key Insight

Traditional privacy approaches hide data from everyone or from no one. RSCP recognizes that different parties have legitimate but different data access needs:

Party	Data Access
Issuer (Company)	Sees ALL data (their database)
Holder (Rider)	Sees ALL data (their credential)
Registry Operator	Sees PUBLIC only (by protocol)
Verifier	Sees DISCLOSED only

MUST: This separation is enforced at the schema level—the protocol literally does not define fields for private attributes in registry records.

2. Architecture

2.1 Participants

RSCP defines five participant roles:

Role	Description	Data Access
Trust Anchor	AutoviaTest.com; publishes protocol, manages issuer registry	Protocol only
Issuer	Company (Swiggy, Uber, etc.) that certifies riders	Full (their credentials)
Registry Operator	Runs verification infrastructure	Public attributes only
Holder	Rider who holds credentials	Full (their credential)
Verifier	Party checking credential validity	Disclosed attributes only

2.2 Trust Model

MUST: Issuers MUST be registered in the Trusted Issuer Registry before issuing credentials. The registry verifies legal entity status and training capability.

SHOULD: Registry operators SHOULD implement redundancy and high availability to ensure verification services remain accessible.

3. Identifier Format

3.1 Certificate Number

RSCP defines a human-readable certificate number format with built-in error detection:

text

RS-{YEAR}-{LEVEL}-{COUNTRY}-{ISSUER}-{SERIAL}-{CHECK}

Example: RS-2026-G-IN-SWG-000001-7

Components:
├── RS: Protocol prefix
├── 2026: Issuance year
├── G: Level (B=Bronze, S=Silver, G=Gold)
├── IN: ISO 3166-1 alpha-2 country code
├── SWG: Registered issuer code (3 characters)
├── 000001: 6-digit serial number
└── 7: ISO 7064 MOD 11,10 check digit

MUST: Certificate numbers MUST include a valid ISO 7064 MOD 11,10 check digit for error detection.

3.2 Verification Code

A compact 8-character code for QR verification, using a confusion-resistant character set:

text

Format: {7 random}{1 check} displayed as XXXX-XXXX

Example: A3B7K9M2 → A3B7-K9M2

Character set: ABCDEFGHJKMNPQRSTUVWXYZ23456789
(Excludes: 0, O, 1, I, L to avoid confusion)
Check digit: Damm algorithm

3.3 Credential URN

Machine-readable credential identifier:

text

urn:rscp:credential:{issuer}:{year}{level}{serial}:{check}

Example: urn:rscp:credential:swiggy:2026G000001:7

4. Credential Structure

4.1 Full Credential (W3C VC 2.0)

The complete credential follows W3C Verifiable Credentials Data Model 2.0:

json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://rscp.org/credentials/v1"
  ],
  "id": "urn:rscp:credential:swiggy:2026G000001:7",
  "type": ["VerifiableCredential", "RoadSafetyCertification"],

  "issuer": {
    "id": "did:rscp:issuer:swiggy",
    "name": "Swiggy Private Limited",
    "country": "IN"
  },

  "validFrom": "2026-01-15T00:00:00Z",
  "validUntil": "2027-01-15T00:00:00Z",

  "credentialSubject": {
    "id": "did:key:z6MkhaXgBZDvotDkL...",
    "certificateNumber": "RS-2026-G-IN-SWG-000001-7",
    "verificationCode": "A3B7K9M2",
    "givenName": "Rahul",
    "familyName": "Kumar",
    "level": "gold",

    // Private attributes (NOT in registry)
    "email": "rahul@email.com",
    "phone": "+91-9876543210",
    "testScore": 92,
    "hazardScore": 88
  },

  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "verificationMethod": "did:rscp:issuer:swiggy#bbs-key-1",
    "proofValue": "u2V0BhVhA..."
  }
}

4.2 Registry Record Schema

The registry stores only the following structure. This schema uses additionalProperties: false to reject any private fields:

json

{
  "publicAttributes": {
    "certificateNumber": "RS-2026-G-IN-SWG-000001-7",
    "givenName": "Rahul",
    "familyName": "Kumar",
    "level": "gold",
    "validFrom": "2026-01-15T00:00:00Z",
    "validUntil": "2027-01-15T00:00:00Z"
  },
  "issuerDid": "did:rscp:issuer:swiggy",
  "issuerSignature": "z3FX...",
  "credentialHash": "sha256:abc123...",
  "status": "active"

  // NO: email, phone, testScore, hazardScore
  // Schema validation REJECTS these fields
}

MUST: Registry implementations MUST validate incoming records against the schema and MUST reject any record containing fields not defined in the schema.

4.3 Certification Levels

Level	Training	Test Threshold	Hazard Threshold	Validity
Bronze	2 hours	70%	N/A	1 year
Silver	4 hours	80%	75%	1 year
Gold	8 hours	85%	85%	2 years

5. Verification Flows

5.1 Basic Verification

Simple QR code scan verification that works with any smartphone:

Verifier scans QR code containing verification code
Browser opens: rscp.org/v/A3B7K9M2
Registry returns public attributes + signature
Verifier sees: name, level, validity, issuer
Verifier does NOT see: email, phone, scores

5.2 Selective Disclosure (BBS+)

For advanced verification where the holder controls what to reveal:

json

// Holder generates selective disclosure proof
{
  "type": "RSCPPresentation",
  "credentialId": "urn:rscp:credential:swiggy:2026G000001:7",

  "disclosed": {
    "givenName": "Rahul",
    "familyName": "Kumar",
    "level": "gold"
  },

  "predicates": [{
    "attribute": "testScore",
    "predicate": ">=",
    "threshold": 80,
    "satisfied": true  // Cryptographically proven!
  }],

  "proof": {
    "type": "BBS+DerivedProof",
    "proofValue": "ABkB9MntC..."
  }
}

MAY: Verifiers MAY request predicate proofs for attributes like test scores. The holder can prove "score >= 80" without revealing the actual value.

6. Privacy Architecture

6.1 Protocol-Level Enforcement

RSCP's privacy guarantees are structural, not policy-based:

Registry cannot store private data - schema validation rejects undefined fields
Verifier sees only disclosed attributes - BBS+ derived proofs reveal only selected messages
Derived proofs are unlinkable - cannot correlate multiple verifications
Predicate proofs hide actual values - Bulletproofs range proofs

6.2 Cryptographic Suite

Purpose	Algorithm	Standard
Credential signing	Ed25519	RFC 8032
Selective disclosure	BBS+	BLS12-381 curve
Hashing	SHA-256	FIPS 180-4
Predicate proofs	Bulletproofs	64-bit range

MUST: Issuers MUST use Ed25519 signatures for credential issuance. BBS+ signatures are REQUIRED for credentials that will support selective disclosure.

6.3 Compliance

RSCP is designed to exceed compliance requirements because the registry simply does not contain personal data:

GDPR Article 17 (Right to erasure): N/A - no personal data to erase
GDPR Article 25 (Privacy by design): Exceeds - protocol-level enforcement
ISO 27701 (Privacy management): Registry is not a PII controller

Have questions?

Join the community