# Credentials in the Internet

[TOC]

In this article, we survey the existing credentials and credential-related standard specifications. The specifications discussed here include:
- [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519)
- [Simple Mail Transfer Protocol (SMTP)](https://datatracker.ietf.org/doc/html/rfc2821)
- [Machine Readable Travel Documents (MRTD) from ICAO](https://www.icao.int/publications/doc-series/doc-9303)
- [Part 7: Machine Readable Visas ](https://www.icao.int/sites/default/files/publications/DocSeries/9303_p7_cons_en.pdf)
- [Part 9: Deployment of Biometric Identification and Electronic Storage of Data in eMRTDs](https://www.icao.int/sites/default/files/publications/DocSeries/9303_p9_cons_en.pdf)
- [Part 12: Public Key Infrastructure for MRTDs]()
- [part 13: Visible Digital Seals for non-electronic documents]()
## JSON Web Token

JSON Web Token =**Base64url(UTF-8(JOSE header))**+**Base64url(UTF-8(Claims)**+**Base64url(HMAC(Base64url(UTF-8(JOSE header)).Base64url(UTF-8(Claims))**

**JOSE Header** declares the type of the encoded object, and the algorithm used in this encoded object.
For example, a JOSE Header can be:

{"typ":"JWT", 
 "alg":"HS256"}

the set of JWT Claims can be:

{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}

There are three classes of JWT Claim Names:Registered Claim Names,Public Claim Names, and Private Claim Names.

### The algorithms supported by JWT specification

Algorithms that MUST be implemented by conforming JWT implementation:
- "HS256": HMAC SHA-256
- "none"

Algorithms that RECOMMENDED be implemented:
- "RS256": RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm
- "ES256": ECDSA using the P-256 curve and the SHA-256 hash algorithm
- Support for other algos and key sizes is OPTIONAL

Support for encrypted JWTs is OPTIONAL.
Algorithms (specific in [JWA](http://www.rfc-editor.org/info/rfc7518)) that MUST be implemented by conforming implmentations:
- "RSA1_5": RSAES-PKCS1-v1_5 with 2048-bit key
- "A128KW" and "A256KW": AES Key Wrap with 128- and 256-bit keys
- "A128CBC-HS256" and "A256CBC-HS512": the composite authenticated encryption algorithm using AES-CBC and HMAC SHA-2

Algorithms that RECOMMENDED be implemented:
- "ECDH-ES+A128KW" and "ECDH-ES+A256KW": using Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) to agree upon a key used to wrap the Content Encryption Key
- "A128GCM" and "A256GCM": AES in Galois/Counter Mode (GCM) with 128- and 256-bit keys

### Practices around JWT

zkLogin utilizes a JWT signed with the RS256 algorithm to derive the public key used for signing transactions in Web3.

## Machine-Readable Travel Document (Passport)

Only hashing and signature algorithms defined in Doc 9303-12 SHALL be used.

Due to the resulting signature size, EllipticCurve Signature Algorithm (ECDSA) with a key length of at least 256 bit in combination with SHA-256 is (at the time thisdocument was created) RECOMMENDED.

The signature sheme used in the specificaiton

The ICAO specification (P11 and P12) mandates that:
- The Document Signer signs the Security Object (SOd) - a data structure that contains the hashed of all data groups (such as personal information, face, fingerprint, etc.)
- The signature sheme used is RSA or ECDSA, following PKCS \#1 or ANSI X9.62/FIPS 186-4 standard,respectively
- **RSA (2048 bits) and ECDSA (P-256 or P-384)** are the most commonly used algorithms.
- The corresponding hash functions are **SHA-256** or stronger (depedning on the security level and the issuinng state).

### Global Interoperability
ICAO defines a Public Key Directory (PKD) which is a central repository for exchanging the information required to authenticate electronic Machine Readable Travel Documents (eMRTDs) such as ePassports, electronic ID cards and Visible Digital Seals.
It allows all countries to exchange Country Signing Certificate Authority (CSCA) and DS certificates securely.

Thus, it ensures that a passport issued in country A can be validated in country B — the cornerstone of cross-border trust.

For now, there are 107 States/Entites have participated in this PKD. The list can be found in this [site](https://www.icao.int/icao-pkd/participants).

### Binding Between Chip and Document

In modern ePassports with Active Authentication (AA) or Chip Authentication (CA):
- The chip holds a private key corresponding to a signed public key.
- During inspection, the chip signs a random challenge to prove it possesses that private key. This prevents chip cloning (a fake chip can’t produce the valid signature).

### Machine-readable Zone of MRTD

The diagram below, taken from the ICAO specifications, summarizes in details how the MRZ is structured.


Document codes are contained within the VIZ (Field 3) and the MRZ (Posiitons 1 and 2). The first letter P shall identify the document as an MRP. The second letter shall identify the document type as per the following table:


## C2PA

Main Problem Addressed:
To verify the origin of media content in order to enhance its credibility. In short, the goal is to solve the provenance problem of certain media content in the digital information world.
“Provenance” empowers content creators and editors—regardless of their geographic location or level of access to technology—to disclose information about who created or modified an asset, what was changed, and how those changes were made.

Contents of the Document:
- The architecture of C2PA (Coalition for Content Provenance and Authenticity).
- The model for storing and retrieving cryptographically verifiable information, along with the corresponding trust model for such verifiable information.


C2PA Information Model:
- C2PA metadata consists of Assertions, which include details such as asset creation, authorship, edit actions, capture device details, and bindings to the content.
An Assertion, together with some additional metadata, is encapsulated into a signed entity called a Claim.
Assertions may also include verifiable credentials (VCs)—as defined by the W3C standard—to provide additional layers of trust.
- These Assertions, Claims, Credentials, and Signatures are bundled by a hardware or software component known as the Claim Generator into a verifiable unit called the C2PA Manifest.

Trust Model:
The identity of the Claim signer may be:

- a pseudonym,
- completely anonymous, or
- associated with a service or trusted hardware device that possesses its own verifiable identity.

Here, “own identity” means that such a service or hardware device has a unique and identifiable marker.
It also includes applications running within those services or trusted hardware devices.

### hash list

The allowed Hash list is:
- SHA2-256
- SHA2-384
- SHA2-512

The SHA-3 family are not on the allowed list for consistency with the digital signature algorithm allowed list, because COSE (RFC 8512) has not yet established digital signature algorithms that use a SHA-3 algorithm as the hash algorithm.

### Signature Algorithms Used by C2PA

The allowed list is:
- ES256/ES384/ES512: ECDSA (P-256/P-384/P-521) with SHA-256/384/512
- PS256/384/512: RSASSA-PSS using SHA-256/384/512 and MGF1 with SHA-256 /384/512
- EdDSA: Ed25519 only.

### Sony's Effort on Supporting C2PA

Sony has extended its existing [still image authentication](https://www.cined.com/sonys-camera-verify-feature-launched-to-strengthen-image-authenticity-for-newsrooms/) system to encompass video content, providing news organizations and broadcasters with tools to verify that footage was captured by a genuine Sony camera rather than generated by artificial intelligence.  The C2PA-compliant solution is now available for five Sony cameras, with four additional models scheduled for support by 2026.

The video authenticity feature launched on **October 30, 2025**, with support for five cameras across Sony’s professional lineup:
- **Interchangeable-lens cameras:** Alpha 1 II and Alpha 9 III
- **Cinema Line cameras:** FX3 and FX30
- **XDCAM memory camcorder:** PXW-Z300 (newly launched)

Sony's [Camera Authenticity Solution](https://authenticity.sony.net/camera/en-us/)