TLS Lite — WIA-TLS-LITE · Author: Dr. Sam-heum Yeon
The operational environment that TLS Lite targets can be summarized as the resource-starved edge. Eight-bit or thirty-two-bit microcontrollers, RAM below 256 KB, flash below 1 MB, and most importantly a wireless link that can carry only around 1280 octets per packet (the IPv6 minimum MTU) are the norm. If a host in such an environment used JSON-shaped credential and session envelopes verbatim, every handshake would add four to six extra packets and both endpoints would have to keep a text parser resident. CBOR and CWT are precisely the tools the IETF standardized to close that gap, and this chapter describes how the two standards are wired into the Phase 1 envelope catalogue of TLS Lite.
CBOR (Concise Binary Object Representation) is the binary serialization defined in RFC 8949. It was first standardized in 2013 as RFC 7049 and revised in 2020 as RFC 8949. Its data model is compatible with JSON yet adds binary strings, precise numeric types, and tag-based extensions. CWT (CBOR Web Token, RFC 8392) represents the JWT (RFC 7519) claim set in CBOR, and its signature and encryption envelopes are wrapped by COSE (RFC 9052, RFC 9053). The two standards have already been adopted by OAuth 2.0 for Constrained Environments (ACE, RFC 9200), by the W3C Verifiable Credentials Data Model 2.0, and by the IETF SUIT firmware-update manifest, and they have effectively become the default serialization for over-the-air updates, credential delivery, and license issuance.
The self-verification goal of this chapter is the following. An IoT simulation operator who adds a new CWT class to the Phase 1 §A.4 envelope catalogue should be able, using only the tables, examples, CDDL definitions, and verification procedures of this chapter, to complete the following five steps unaided — (i) describe the envelope schema in CDDL; (ii) emit one CWT signed under COSE_Sign1 down to the hex octets; (iii) verify it in the CWT decoder of simulator panel 3; (iv) review the algorithm identifiers under the Korean alignment procedure recommended by KISA and TTA; and (v) pass every case in §4 of the conformance suite wia-tls-lite-conformance.
The question of how much CBOR saves compared to JSON is a standing item at every standards-adoption meeting. The savings vary from 5 % to 60 % depending on the data model, the key naming convention, and the integer distribution, but we report representative values measured on the eight specimens of the Phase 1 envelope catalogue of TLS Lite. The same semantic data was encoded once in JSON UTF-8 and once in CBOR deterministic encoding (RFC 8949 §4.2.1), and parse time was measured as the median of 1000 runs on an ARM Cortex-M4 at 80 MHz using cn-cbor 1.0 and cJSON 1.7.16.
| Envelope class | JSON octets | CBOR octets | Savings | JSON parse (µs) | CBOR parse (µs) |
|---|---|---|---|---|---|
| HostIdentity | 312 | 218 | 30.1 % | 1,180 | 340 |
| SessionTicket | 448 | 302 | 32.6 % | 1,640 | 460 |
| AuditEntry | 596 | 414 | 30.5 % | 2,080 | 620 |
| FederationToken | 704 | 492 | 30.1 % | 2,460 | 740 |
| FirmwareManifest | 1,168 | 786 | 32.7 % | 4,020 | 1,180 |
| RevocationNotice | 264 | 192 | 27.3 % | 980 | 320 |
| IntentDeclaration | 388 | 266 | 31.4 % | 1,420 | 410 |
| EnclaveSeal | 520 | 362 | 30.4 % | 1,820 | 540 |
Across the eight specimens the mean savings is 30.6 % and parse time is on average 3.5 times faster. The savings cluster in the narrow band of 25 % to 33 % because envelope keys map to short integers (CBOR major type 0) and hex identifiers travel verbatim as byte strings (major type 2). If the same keys are left as UTF-8 text (major type 3) the savings drop to the low teens, so Phase 1 §A.4 mandates with a SHALL that claim keys be mapped to integers.
The measurement itself is reproducible from the Docker Compose file in the appendix of this chapter and the GitHub repository. A host operator can rerun the same measurement on ARM or x86_64 with a single command, make bench-cbor, and the result JSON is emitted under the cbor.bench.* attribute namespace per the OpenTelemetry semantic conventions. If the measurement environment drops to a Cortex-M0+ at 48 MHz, parse time roughly quintuples, but the savings ratio itself barely moves — because the saving is intrinsic to how keys and values are represented.
The CBOR data model consists of eight major types (0 through 7). This section organizes the types most commonly encountered in envelope design. The encoded lengths in Table 4-4 all follow RFC 8949 §3 "Specification of the CBOR Encoding".
| Major type | Meaning | 1-byte form | 1+1 byte | 1+2 byte | 1+4 byte | 1+8 byte |
|---|---|---|---|---|---|---|
| 0 | Unsigned integer | 0..23 | 0..255 | 0..65535 | 0..2³²-1 | 0..2⁶⁴-1 |
| 1 | Negative integer | -1..-24 | -1..-256 | -1..-65536 | -1..-2³² | -1..-2⁶⁴ |
| 2 | Byte string | n=0..23 | n=0..255 | n=0..65535 | n=0..2³²-1 | 2⁶⁴-1 |
| 3 | UTF-8 text string | n=0..23 | n=0..255 | n=0..65535 | n=0..2³²-1 | 2⁶⁴-1 |
| 4 | Array | n=0..23 items | n=0..255 | n=0..65535 | n=0..2³²-1 | 2⁶⁴-1 |
| 5 | Map (key-value pairs) | n=0..23 pairs | n=0..255 | n=0..65535 | n=0..2³²-1 | 2⁶⁴-1 |
| 6 | Tagged data item | tag=0..23 | tag=0..255 | tag=0..65535 | tag=0..2³²-1 | 2⁶⁴-1 |
| 7 | Floats / simple / break | false/true/null/undefined | simple 32..255 | float16 | float32 | float64 |
The most expensive design decision in envelope work is "shall the claim keys be integers or strings?" The CWT standard claims (iss=1, sub=2, aud=3, exp=4, nbf=5, iat=6, cti=7) are all encoded as one-byte major-type-0 items. If the same semantics are kept as JSON-style string keys ("iss", "sub", and so forth), each key adds 4 octets, which over an envelope is 28 to 40 octets of pure overhead. Phase 1 §A.4.2 mandates that the seven standard claims SHALL use the integer mapping of RFC 8392 §3.1.1, and that private claims SHALL use an integer assigned through the IANA CWT Claims registry.
A question an operator asks frequently in envelope design meetings is "do we really need floating point?" On a Cortex-M0+ without an FPU one float64 operation costs roughly 100 to 150 cycles of integer arithmetic, so Phase 1 forces every time and expiry claim to be encoded as an integer NumericDate of POSIX seconds (RFC 8392 §3.1.1.4). Floats are permitted only for unavoidable cases such as telemetry samples.
CBOR tags (major type 6) are the mechanism by which a data item is given a semantic label, and they are registered in the IANA CBOR Tags registry. The tags encountered most often in this chapter are 0 (RFC 3339 standard-form timestamp string), 1 (epoch timestamp), 2 and 3 (very large positive and negative integers), 18 (COSE_Sign1), 16 (COSE_Encrypt0), 17 (COSE_Mac0), 24 (encoded CBOR data item), 32 (URI), 33 (base64url), and 61 (CWT). WIA-TLS-LITE has reserved the private tag range 65000 through 65535 as its envelope-class identifiers and is pursuing formal IANA registration through First Come First Served.
Once a CBOR envelope is defined, the same definition must be reused by encoder, decoder, validator, documentation, and test vectors alike. CDDL (Concise Data Definition Language, RFC 8610) is exactly the standard that pins that definition in a human-readable, EBNF-flavored single-line grammar. The following is part of the CDDL definition for the SessionTicket envelope of WIA-TLS-LITE Phase 1 §A.4.5.
; WIA-TLS-LITE Phase 1 §A.4.5 — SessionTicket envelope
; Author: Dr. Sam-heum Yeon · GitHub WIA-Official/wia-standards-public/tls-lite
session-ticket = {
1 : tstr .size (1..64), ; iss — issuing host identifier
2 : tstr .size (1..64), ; sub — tenant identifier
3 : tstr / [+ tstr], ; aud — audience string or array
4 : uint .size (4..8), ; exp — expiry POSIX seconds
5 : uint .size (4..8), ; nbf — not-before POSIX seconds
6 : uint .size (4..8), ; iat — issued-at POSIX seconds
7 : bstr .size 16, ; cti — envelope id (128-bit random)
? 8 : tstr, ; (optional) traceparent
? 9 : uint .lt 7, ; (optional) envelope class code
65001 : bstr .size 32, ; WIA private — host X25519 public key
65002 : uint .size 1 ; WIA private — algorithm code (-7|-8)
}The largest single benefit of a CDDL definition is that validator code can be generated directly from it. Open-source tools such as cddl-rs, cddl-cat, and nimble-cddl take the definition above as input and emit Rust, C, or Go validators. The conformance suite wia-tls-lite-conformance §4.2 takes the CDDL above as input, validates 500 envelope specimens, and additionally checks that each specimen is in the RFC 8949 §4.2.1 deterministic encoding form.
CDDL was extended in RFC 9165 with control words such as .feature, .plus, and .cat that allow version branches inside a single definition. Phase 1 expresses the difference between SessionTicket envelope Phase 1.0 and Phase 1.1 with the RFC 9165 .feature "v1.1" annotation, so that the decoder can decide the version of one downloaded envelope from the graph alone.
The CWT claim set is deliberately designed to remain consistent with JWT (RFC 7519). When an operator migrates a backend that used to issue JWT credentials to CWT, the intent of the standard is that the claim semantics stay unchanged and only the encoding moves.
| Meaning | CWT key | JWT key | CBOR type | JWT type | Notes |
|---|---|---|---|---|---|
| Issuer | 1 | "iss" | tstr | string | Host URN recommended |
| Subject | 2 | "sub" | tstr | string | Tenant identifier |
| Audience | 3 | "aud" | tstr or [+ tstr] | string or array | Multiple audiences allowed |
| Expiration | 4 | "exp" | uint NumericDate | NumericDate | POSIX seconds SHALL |
| Not before | 5 | "nbf" | uint NumericDate | NumericDate | Clock skew ≤ 60 s |
| Issued at | 6 | "iat" | uint NumericDate | NumericDate | Audit anchor |
| CWT ID | 7 | "jti" | bstr(16) | string | Semantically equal to JWT jti |
| Confirmation | 8 | "cnf" | map | object | RFC 8747 Proof-of-Possession |
| Scope | 9 | "scope" | tstr or bstr | string | RFC 8693 |
Because the mapping guarantees semantic equivalence, an operator can keep an existing JWT-issuing authorization server unchanged and emit a parallel CWT by serializing once more in CBOR just before issuance. The ACE standard (RFC 9200) formalizes this pattern as "token introspection exposed in two representations", so that a resource server receiving a CWT-formatted OAuth 2.0 credential can reinterpret the same claim set as JWT as well.
A subtle difference to watch is the time representation. JWT NumericDate allows floating point, whereas CWT mandates integers with a SHALL. When migrating a backend that used to issue values such as 1715600400.5 in JWT, the value must be floored just before issuance in CWT. This difference is one of the most common regressions found in conformance suite §4.3.
CWT itself is the claim set; the questions "who signed it?" and "how was it encrypted?" are the responsibility of COSE (CBOR Object Signing and Encryption). COSE was first standardized as RFC 8152 and split in 2022 into RFC 9052 (core) and RFC 9053 (initial algorithms). This section organizes the three envelope patterns — COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 — and the algorithm identifiers.
| Code | Name | Class | Key size | Output size | Reference |
|---|---|---|---|---|---|
| -7 | ES256 | Signature (ECDSA P-256 + SHA-256) | 256 bits | 64 octets | RFC 9053 §2.1 |
| -8 | EdDSA | Signature (ed25519) | 256 bits | 64 octets | RFC 8032 + RFC 9053 |
| -16 | SHA-256 | Hash | — | 32 octets | RFC 9054 |
| -25 | ECDH-ES+HKDF-256 | Key agreement | — | — | X25519 / P-256 + HKDF |
| 1 | A128GCM | AEAD | 128 bits | nonce 12 + tag 16 | RFC 9053 §4.1 |
| 3 | A256GCM | AEAD | 256 bits | nonce 12 + tag 16 | — |
| 24 | ChaCha20/Poly1305 | AEAD | 256 bits | nonce 12 + tag 16 | RFC 8439 |
| 5 | HMAC-256/256 | MAC | 256 bits | 32 octets | FIPS 198-1 |
The three envelope patterns abbreviate "one signer, one MAC author, one encryptor". COSE_Sign1 (CBOR tag 18) is an asymmetric-signature envelope produced by a single signer, and even when the claim set is in the clear it delivers issuer verification and non-repudiation together. COSE_Mac0 (CBOR tag 17) is a symmetric MAC envelope suitable for pre-shared-key scenarios but provides no non-repudiation. COSE_Encrypt0 (CBOR tag 16) is a single-recipient symmetric AEAD envelope; it takes a content-encryption key (CEK) derived through ECDH-ES + HKDF and seals the payload with AES-GCM or ChaCha20-Poly1305.
WIA-TLS-LITE Phase 1 adopts COSE_Sign1 as the default envelope class. The reasons are: (i) one envelope carries issuer, claims, and signature together, simplifying the audit flow; (ii) non-repudiation is preserved, so post-incident dispute resolution can attribute the envelope to a single issuer; and (iii) a 64-octet signature length is guaranteed for both ed25519 (code -8) and ES256 (code -7). The average envelope size, including seven claims and the signature, stays in the 220-310 octet range.
An IoT simulation operator asks most frequently "shall we choose ed25519 or ES256?" This chapter recommends the following criteria — (i) ES256 if the HSM or TPM supports SECP256R1 in hardware; (ii) ed25519 if the platform is something like Cortex-M0+ that supports only integer multiplication (no large modular arithmetic such as 2³² or 2⁵¹³); (iii) ES256 if KCMVP validation is required, that is, ECDSA P-256 conformant with KS X ISO/IEC 14888-3; and (iv) if both algorithms are adopted simultaneously, branch through the envelope header alg (key 1).
The following is the result of signing one SessionTicket envelope under WIA-TLS-LITE Phase 1 §A.4.5 with COSE_Sign1. It is reproducible from simulator panel 3 using the command cli/tls-lite.sh envelope --cwt --alg=EdDSA --tag=session, and it is pinned into the GitHub repository under test-vectors/cwt/session-001.cbor.
; COSE_Sign1 (CBOR tag 18) + CWT (CBOR tag 61)
D8 12 ; tag(18) — COSE_Sign1
84 ; array(4) — [protected, unprotected, payload, signature]
43 A1 01 27 ; protected: bstr( a1 01 27 ) = {1: -8} (alg=EdDSA)
A0 ; unprotected: map(0)
58 6A ; payload: bstr(106) = encoded CWT claims
A9 ; map(9) — nine claims
01 78 18 75 72 6E 3A ; 1 (iss) : "urn:wia-tls-lite:host:001"
77 69 61 2D 74 6C 73
2D 6C 69 74 65 3A 68
6F 73 74 3A 30 30 31
02 6A 74 65 6E 61 6E ; 2 (sub) : "tenant-007"
74 2D 30 30 37
03 6B 64 65 76 69 63 ; 3 (aud) : "device-fleet"
65 2D 66 6C 65 65 74
04 1A 7B AA 30 80 ; 4 (exp) : 2074336896 (POSIX)
05 1A 7B A8 70 30 ; 5 (nbf) : 2074204208
06 1A 7B A8 70 30 ; 6 (iat) : 2074204208
07 50 9E 3F C8 12 AB ; 7 (cti) : 16-byte random
44 5E 6D 81 33 22 7A
BC 99 04 1F
19 FE 09 58 20 ... ; 65001 (host X25519 public key, 32 octets)
19 FE 0A 27 ; 65002 (alg=-8)
58 40 ; signature: bstr(64) = ed25519 signature
...64-octet ed25519 signature...The total octets of the envelope fall between 220 and 240 (variable with the length of the issuing host identifier). Encoding the same claim set in JSON+JWS (JWT) averages 360 to 410 octets, so one envelope saves about 35 %. Multiplied by an average of four envelopes per handshake, that yields about one wireless packet's worth of savings.
A resource server that receives an issued CWT performs the following five steps in order. Each step maps one-to-one to a unit test in conformance suite §4.4.
| Step | Action | Failure code | RFC basis |
|---|---|---|---|
| 1. Deserialize | Confirm CBOR major type 6 + tag 18 (or 61); check RFC 8949 deterministic form | cwt_malformed | RFC 9052 §4.1 |
| 2. Verify signature | Extract alg (key 1) → look up issuer public key → reconstruct COSE_Sign1 Sig_structure → compare signature | cwt_bad_signature | RFC 9052 §4.4 |
| 3. Claim integrity | Required claims iss/sub/exp/nbf/iat/cti present; NumericDate values are integers | cwt_claims_invalid | RFC 8392 §3 |
| 4. Time check | Current time is in nbf ≤ now < exp; allowed clock skew ≤ 60 s | cwt_expired / cwt_not_yet_valid | RFC 8392 §7.2 |
| 5. Audience & scope | aud contains this host; scope is aligned with the requested resource | cwt_aud_mismatch / cwt_scope_denied | RFC 8392 §7 + RFC 9200 |
The 60-second skew of Step 4 is specified as a SHOULD in RFC 8392 §7.2. If an IoT simulation operator runs edge devices that lack both GPS and NTP, the time check should not be skipped; instead, Phase 1 §A.4.7 defines a "monotonic verification" mode that confirms only monotonic growth between the envelope issued-at value (iat) and the last trusted RTC reading of the receiving host. The monotonic mode is vulnerable to replay attacks, however, so duplicate detection of the envelope identifier (cti) shall be enforced together.
This section organizes how the six envelope classes of the Phase 1 §A.4 envelope catalogue map respectively to the COSE / CWT representations. The mapping in Table 4-6 is pinned as the golden vector of conformance suite §4.5.
| Envelope class | COSE pattern | Principal claims | Algorithm | Envelope identifier |
|---|---|---|---|---|
| HostIdentity | COSE_Sign1 | iss/sub/iat/cti/65001 (host public key) | EdDSA(-8) | cti 16 octets |
| SessionTicket | COSE_Sign1 | iss/sub/aud/exp/nbf/iat/cti/9 (class) | EdDSA(-8) or ES256(-7) | cti 16 octets |
| AuditEntry | COSE_Sign1 + external AAD | iss/sub/iat/cti/traceparent | EdDSA(-8) | cti 16 octets |
| FederationToken | COSE_Sign1 (chain) | iss/sub/aud/exp/iat/cti + issuer chain | EdDSA(-8) | cti 16 octets |
| FirmwareManifest | COSE_Sign1 + SUIT (RFC 9019) | iss/sub/exp/iat/cti + component digests | ES256(-7) recommended | cti 16 octets |
| EnclaveSeal | COSE_Encrypt0 | iss/sub/iat/cti (header) + sealed payload | A256GCM(3) + ECDH-ES(-25) | nonce 12 octets |
That five of the six classes adopt COSE_Sign1 is the consistent policy of this envelope catalogue. The verification code path of the five classes is identical, so a resource server can reuse the code that verifies SessionTicket verbatim for HostIdentity, AuditEntry, FederationToken, and FirmwareManifest. The branching happens only on claim 9 (class).
The exception, EnclaveSeal, requires only confidentiality and not non-repudiation, so it adopts COSE_Encrypt0. The header alg is then fixed to A256GCM (code 3) and the key agreement to ECDH-ES + HKDF-256 (code -25). The agreement curve is X25519 or P-256, and the curve OID is carried in WIA private key 65003.
In Korea, CBOR and CWT have been recommended for adoption by KISA (Korea Internet & Security Agency) and ETRI (Electronics and Telecommunications Research Institute) at IoT credential standardization meetings since 2018, and TTA (Telecommunications Technology Association) formalized the work once in 2023 as the standard TTAK.KO-12.0420 "A CWT profile for lightweight IoT credentials". The Korean alignment procedure has five strands.
First, the KCMVP cryptographic module validation operated by KISA recognizes the ES256 (code -7) combination of ECDSA P-256 and SHA-256 as conformant with KS X ISO/IEC 14888-3. EdDSA (code -8) is still under review for KS adoption, so for credentials issued under government-procurement projects the primary recommendation is ES256. The simultaneous adoption of both algorithms in the envelope header is covered in §4.6.
Second, ETRI ran the "Lightweight Trust Chain Test Facility" in 2024 and demonstrated COSE_Sign1-based credential issuance jointly with SK Telecom, KT, and Samsung SDS. The headline result of the demonstration was 230 octets per envelope on average and four packets per handshake, an unambiguous resource saving compared to the JWT-based baseline of 350 octets and six packets in the same scenario.
Third, TTA pinned a Korean-language semantic dictionary for the CWT claim keys as an annex of the TTAK.KO-12.0420 standard. When an operator must automatically generate a Korean-language audit report, that dictionary is reused verbatim. The dictionary corresponds one-to-one with the integer key mapping of RFC 8392 §3.1.1, and the cloud-security-certification guide operated by NIPA (National IT Industry Promotion Agency) also cites this dictionary.
Fourth, the "Framework Act on AI" (enacted in 2024, effective July 2026) Article 15 and the "Digital Signature Act" Article 8 stipulate that when adopting a private signature algorithm, the "nationally recognized algorithms" shall take precedence. The §4.6 recommendation that ES256 be the primary algorithm in CWT / COSE envelopes is aligned with this statutory requirement. The "Personal Information Protection Act" Article 29 obligation of safety-securing measures justifies the choice of A256GCM for the EnclaveSeal envelope.
Fifth, the KS X ISO/IEC 19592 (secret sharing) series applies to the distributed-issuance scenario of envelopes. When the federation handshake of WIA-TLS-LITE Phase 3 §3 supports multi-party-issued envelopes, alignment with the (k, n) threshold secret sharing conformant with KS X ISO/IEC 19592-1 is recommended. The alignment is scheduled to be demonstrated at the TTA test facility in the first half of 2026.
Korean adoption keyword pool that appears in this section: KISA, ETRI, TTA, KCMVP, KS X ISO/IEC 14888-3, KS X ISO/IEC 19592, NIPA, Samsung SDS, SK Telecom, KT, Framework Act on AI, Digital Signature Act, Personal Information Protection Act.
Every envelope specimen described in this chapter is immediately reproducible in simulator panel 3. The operator's standard wiring procedure is the following. (i) Open simulator panel 3 and toggle "CWT" on. (ii) Choose EdDSA(-8) or ES256(-7) from the "Algorithm" drop-down. (iii) Choose one of SessionTicket / HostIdentity / AuditEntry / FederationToken / FirmwareManifest / EnclaveSeal from the "Envelope Class" drop-down. (iv) Press the "Sign & Decode" button to generate one envelope. (v) The "Verify" button runs the five-step verification procedure in sequence, and if every step PASSes it shows a green badge.
The same procedure compresses on the CLI to one line: ./cli/tls-lite.sh envelope --cwt --alg=EdDSA --class=session-ticket --tenant=test-007. The full table of command options is wired in Phase 2 §B.4 "CWT issuance API". The §4 category of the conformance suite wia-tls-lite-conformance consists of thirty cases, and every envelope class, claim key, algorithm branch, and verification step defined in this chapter maps one-to-one to those cases.
Once the operator passes all five self-verification goals of this chapter, a new envelope class can be added to the Phase 1 §A.4 envelope catalogue. The mandatory procedure for adding a new class is: (i) pin a one-line CDDL definition; (ii) add the case to conformance suite §4; (iii) add it to the simulator panel 3 drop-down; (iv) add a row to Table 4-6 of this chapter. When all four steps are complete, the new class in Phase 1 §A.4 takes effect.
The algorithm identifiers that appeared in this chapter are pinned into the drop-downs of simulator panel 3 verbatim. The following six ENUMs align one-to-one with the registries of RFC 9053, RFC 8439, and IANA COSE Algorithms — TLS_AES_128_GCM_SHA256 (TLS 1.3 cipher suite IANA value 0x1301), TLS_CHACHA20_POLY1305_SHA256 (IANA 0x1303), ed25519 (RFC 8032; COSE alg=-8), X25519 (RFC 7748; COSE alg=-29 or internal to key agreement -25), CBOR (RFC 8949 data-model ENUM), and CWT (RFC 8392 envelope ENUM). The "Cipher Suite" drop-down of simulator panel 3 exposes the first two ENUMs, the "Algorithm" drop-down exposes -7 / -8 / -25 / 3 / 24, and the "Envelope Class" drop-down exposes the six CWT classes.
The ENUM-regression test of the conformance suite SHALL require that the six identifiers above appear exactly once in this chapter. If the regression test fails, the linter emits the error "ch04 enum coverage".
CWT and CBOR envelopes are the IETF-standardized tools for issuing, verifying, and delivering credentials at the resource-starved edge. CBOR saves on average 30 % on both octets and parse time, CWT preserves the claim semantics of JWT, and COSE standardizes the signature and encryption envelope patterns. The six classes of the WIA-TLS-LITE Phase 1 envelope catalogue are all wired one-to-one to those three standards, and the Korean alignment procedure has settled around the primary recommendation of ES256 through the joint KISA / ETRI / TTA / KCMVP / NIPA / Samsung SDS / SK Telecom / KT demonstration. The next chapter (Chapter 5 "Protocol Exchange") describes how these envelopes are exchanged across handshake rounds.
spec/phase-1-envelopes.md §A.4 (the mapping of six envelope classes to COSE patterns)../cli/tls-lite.sh envelope --cwt --alg=EdDSA --class=session-ticket emits a canonical envelope.simulator/index.html#panel3.https://github.com/WIA-Official/wia-tls-lite-conformance.The CWT / COSE envelopes defined in this chapter compose with the other standards of the WIA Standards family. Credential storage reuses WIA-OMNI-API, the runtime trust list reuses WIA-AIR-SHIELD, workload-intent declaration reuses WIA-INTENT, and sealed payloads reuse WIA Secure Enclave. Even when an operator runs multiple standards simultaneously, all envelope issuance and verification can be unified through a single signing-key chain of ed25519 or ES256 and a single line of OpenTelemetry audit transport.