ARS-1 -- Generic Archival Reference System

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Status: v1.0-rc2 (Frozen) Protocol class: Generic archival reference and permalink protocol¶

Revision: v1.0-rc2 introduces the formal ARS Profile Registry model, separates Profile Identifier from Profile Version to eliminate semantic redundancy (Identifier ARS1-REF + Version 1 instead of ARS1-REF-1), and adds IANA Considerations. The normative Profile v1 test vector (Section 79) has been regenerated to reflect the split Identifier. All prior rc1 vectors are superseded. The specification is frozen as of v1.0-rc2.¶

Conformance: The normative test vector (Section 79) has been regenerated for v1.0-rc2 following the Profile Identifier split (ARS1-REF + Version 1). The values have been cross-verified by 23 independent implementations producing identical output. This does NOT constitute a cryptographic security audit.¶

2. Abstract

ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities.¶

Typical visual forms include:¶

    NX-174932
    CJ3-106
    MR-X4928
    KX4-7B19Q2

ARS does not assign business meaning to Prefixes.¶

For example:¶

    NX -> Project

is an Application Profile decision, not an ARS-1 rule.¶

ARS-1 defines:¶

    Cryptographic Identity
    Deterministic Derivation
    Namespace
    Prefix Registry
    Canonical Serialization
    Variable-Length Encoding
    Checksum
    Optional Hardware Input
    Optional Digital Signature
    Cryptographic Agility
    Versioning
    Portability
    Reference Resolution
    Reference Reproduction
    Cryptographic Migration

The core interoperability property is:¶

Identical canonical inputs, identical applicable cryptographic Profile, identical Reference Key material, and identical Hardware Profile output MUST produce exactly the same canonical Reference in every conforming implementation.¶

ARS-1 is designed so that changes in cryptographic algorithms, security parameters, signature schemes, or hardware mechanisms can be introduced through versioned Profiles without requiring the reassignment of historical References.¶

3. Normative Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174].¶

A conforming implementation MUST treat all normative serialization, derivation, encoding, verification, migration, and versioning rules as exact protocol requirements.¶

4. Protocol / Application Separation

ARS-1 defines the protocol.¶

    ARS-1
    |
    +-- Reference Grammar
    +-- Cryptographic Derivation Interface
    +-- Canonical Serialization
    +-- Encoding
    +-- Checksum
    +-- Hardware Input Interface
    +-- Cryptographic Profile Interface
    +-- Signature Profile Interface
    +-- Verification
    +-- Resolution Semantics
    +-- Reproduction Semantics
    +-- Migration Semantics
    +-- Protocol Versioning
            |
            [U+25BC]
    Application Profile
    |
    +-- Namespace
    +-- Prefix Registry
    +-- Entity Identity Format
    +-- Reference Cryptographic Profile
    +-- Reference Key Policy
    +-- Data Bit Length
    +-- Maximum Payload Length
    +-- Checksum Policy
    +-- Hardware Profile
    +-- Signature Profile
    +-- Collision Policy
    +-- URL Policy

ARS-1 MUST NOT require any specific:¶

    Namespace
    Prefix
    database
    hardware vendor
    URL structure
    entity model
    UI convention
    cryptographic signature algorithm

5. Core Identity Architecture

ARS separates the following mechanisms:¶

    Root Secret
         v
    Reference Cryptographic Profile
         v
    Reference Key
         v
    Reference Material
         v
    Public Reference

Optional:¶

    Hardware Secret
         v
    Hardware Profile
         v
    Canonical Challenge
         v
    Deterministic Hardware Response
         v
    Canonical Hardware Input

Independent:¶

    Signing Key
         v
    Signature Profile
         v
    Digital Signature

Independent:¶

    State Root / Content Hash
         v
    Historical Content Integrity

These mechanisms MUST NOT be treated as interchangeable.¶

6. Determinism Invariant

Let:¶

    T = CanonicalReferenceRecord
    K = Reference Key
    P = Reference Cryptographic Profile

Then:¶

    R = F(T, K, P)

MUST satisfy:¶

    T1 = T2
    K1 = K2
    P1 = P2
        v
    F(T1, K1, P1) = F(T2, K2, P2)

Reference derivation MUST NOT depend on hidden runtime state.¶

The following MUST NOT affect Reference derivation unless explicitly included in a canonical protocol field:¶

    random()
    nonce
    current time
    database sequence
    process ID
    machine ID
    MAC address
    thread state
    memory address
    filesystem ordering
    network state
    runtime entropy

7. Root Secret

The ARS Root Secret is the root symmetric secret from which Reference Keys are deterministically derived.¶

A Reference Cryptographic Profile defines the required Root Secret security level.¶

The ARS-1 Default Reference Cryptographic Profile Version 1 requires:¶

    Root Secret = 256 bits

Root Secret material MUST be generated using a cryptographically secure random number generator.¶

A human password MUST NOT be used directly as a Root Secret or Reference Key.¶

Future Reference Cryptographic Profiles MAY define larger Root Secrets or different approved secret-generation requirements.¶

8. Root Secret Protection

Root Secret:¶

• MUST NOT be stored in plaintext in ordinary configuration files.¶
• MUST NOT be committed to source control.¶
• MUST NOT be embedded in frontend code.¶
• MUST NOT appear in ordinary logs.¶
• MUST NOT be exposed through ordinary application exports.¶

Implementations SHOULD use protected storage such as:¶

    OS Key Store
    Encrypted Keystore
    HSM
    Secure Element
    TPM-backed storage

Encrypted backups SHOULD use authenticated encryption.¶

If a password protects an encrypted backup, the backup key SHOULD be derived using an appropriate memory-hard password KDF.¶

The password itself MUST NOT become the Reference Key.¶

9. Cryptographic Key Separation

Root Secret MUST NOT be reused directly for unrelated cryptographic purposes.¶

Reference derivation MUST use its own domain-separated cryptographic context.¶

Signing keys MUST be independently defined.¶

Conceptually:¶

    Root Secret
       |
       +-- reference-root
       +-- export
       +-- future purpose-specific domains

A Signing Private Key MUST NOT be treated as the Root Secret.¶

A Hardware Response Secret MUST NOT be treated as the Root Secret.¶

10. Reference Cryptographic Profile

A Reference Cryptographic Profile defines the cryptographic construction used to derive a Reference.¶

A Profile MUST define at least:¶

    profile identifier
    profile version
    security target
    root secret requirements
    key derivation algorithm
    hash or PRF algorithm
    Reference Key construction
    Reference Material construction
    Reference Material length
    domain separation rules
    security assumptions
    deprecation status

The Profile is part of the ARS Reference context.¶

A Profile's cryptographic identity is the ordered pair:¶

    profile identifier
    profile version

The Profile Identifier MUST be explicit, immutable for that Profile definition, and unique within the applicable ARS protocol ecosystem. The Profile Version MUST be explicit. A Profile MUST NOT reuse an existing Identifier + Version pair for a different construction.¶

ARS-1 Default Reference Cryptographic Profile Version 1 is:¶

    Profile Identifier:
        ARS1-REF

    Profile Version:
        1

    Security Target:
        approximately 128-bit classical symmetric security
        under the security assumptions of the selected primitives

    Root Secret:
        256 bits

    Reference Key:
        256 bits

    KDF:
        HKDF-SHA-256

    Reference Material:
        256 bits

The Profile Identifier (ARS1-REF) and Profile Version (1) together form the Profile Identity as defined in Section 9. The Identifier MUST NOT include a version suffix; version is always a separate field.¶

The Security Target is an engineering target, not a permanent cryptographic guarantee.¶

A future Profile MAY define a different Security Target and different cryptographic parameters.¶

The exact construction of Profile Version 1 is specified by later normative sections.¶

11. Cryptographic Agility

ARS-1 is designed for cryptographic agility.¶

Cryptographic agility means that a conforming deployment can replace or add cryptographic mechanisms while preserving the identity, storage, and operational continuity of previously issued References.¶

A future Reference Cryptographic Profile MAY change:¶

    hash function
    KDF
    PRF construction
    Root Secret size
    Reference Key size
    Reference Material size
    domain separation construction
    security target

provided the new Profile is explicitly versioned.¶

A future Signature Profile MAY change:¶

    signature algorithm
    public-key representation
    signature encoding
    certificate representation
    security target

without altering the associated Public Reference.¶

A future Hardware Profile MAY change:¶

    challenge construction
    hardware operation
    response algorithm
    truncation
    encoding
    hardware credential mechanism
    security target

without altering already issued References.¶

An implementation MUST NOT silently substitute a new cryptographic construction under an existing Profile Version.¶

Cryptographic agility does NOT require two different Cryptographic Profiles to derive the same Reference from otherwise identical inputs.¶

Each historical Reference remains bound to the Cryptographic Profile under which it was issued.¶

12. Reference Key Derivation

For Reference Cryptographic Profile profile_id, version profile_version, and Reference Key Version v:¶

    PRK =
    HKDF-Extract(
        salt = UTF8("ARS-1/reference-root-salt"),
        IKM  = RootSecret
    )

Then:¶

    ReferenceKey(v) =
    HKDF-Expand(
        PRK,
        info = UTF8("ARS-1/reference-root/v") ||
               UINT8(length(PROFILE_ID_BYTES)) ||
               PROFILE_ID_BYTES ||
               UINT16_BE(profile_version) ||
               UINT32_BE(v),
        L = 32
    )

PROFILE_ID_BYTES is the exact canonical UTF-8 byte representation of the Reference Cryptographic Profile Identifier.¶

The Profile Identifier and Profile Version are cryptographically bound to Reference Key derivation.¶

The result is exactly:¶

    32 bytes
    256 bits

ARS-1 Reference Cryptographic Profile Version 1 uses HKDF-SHA-256 [RFC5869].¶

Future Profiles MAY define a different key derivation construction.¶

13. Reference Key Version

Every Reference Key has an explicit version:¶

    1
    2
    3
    ...

Reference Key Version MUST be part of the canonical Reference context.¶

Changing Reference Key Version MUST NOT rewrite historical References.¶

Example:¶

    v1
    -> historical References

    v2
    -> References issued under the new key context

Reference Key Version and Reference Cryptographic Profile Version are distinct dimensions.¶

A Profile Version identifies the cryptographic construction.¶

A Reference Key Version identifies the key-generation context within that construction.¶

Reference Key Version is a public derivation-domain identifier. It does not itself provide forward secrecy or recovery from Root Secret compromise; see Section 84.1.¶

14. Protocol and Profile Version Separation

ARS distinguishes at least:¶

    protocol_version
    application_profile_id
    application_profile_version
    reference_cryptographic_profile_id
    reference_cryptographic_profile_version
    reference_key_version
    hardware_profile_id
    hardware_profile_version

These values MUST NOT be collapsed into one generic version field.¶

Application Profile ID + Application Profile Version defines application-specific semantics.¶

Reference Cryptographic Profile ID + Reference Cryptographic Profile Version defines cryptographic Reference derivation.¶

Reference Key Version identifies the Reference key context within the selected cryptographic Profile.¶

Hardware Profile ID + Hardware Profile Version defines hardware-derived input construction.¶

Only fields explicitly defined as derivation inputs SHALL affect Reference derivation.¶

Signature Profile Version MUST NOT affect Reference derivation.¶

A conforming implementation MUST NOT infer a Profile solely from a numeric version.¶

15. Identity Generation

An Application Profile MAY define an Identity Generation value.¶

Default type:¶

    uint32

Identity Generation distinguishes different long-lived cryptographic identity contexts.¶

It is NOT:¶

    entity number
    creation sequence
    revision number

Example:¶

    Identity Generation = 1

After an explicit identity-generation transition:¶

    Identity Generation = 2

16. Stable Entity Identity

Every Referenceable Entity MUST have an immutable Entity Identity.¶

Permitted forms MAY include:¶

    UUID
    UUIDv7
    ULID
    application-defined immutable identifier

Entity Identity is the durable identity of the entity.¶

It does not need to resemble the Public Reference.¶

A database primary key MUST NOT automatically be assumed to be an ARS Public Reference.¶

17. First Creation Time

First Creation Time is archival metadata describing:¶

the first time an entity became a durable entity in the ARS-enabled system.¶

It MAY be used by the Application Profile as immutable archival metadata.¶

Default representation:¶

    UTC
    milliseconds since Unix Epoch
    uint64

Example:¶

    2026-08-20T12:34:56.789Z

is represented by its corresponding unsigned 64-bit Unix-millisecond value.¶

First Creation Time is NOT a canonical Reference derivation input in ARS-1 v1.¶

This prevents Reference instability caused by later correction of archival metadata.¶

Therefore:¶

    Entity Identity
    +
    Reference Context

defines the cryptographic identity of the Reference, while:¶

    First Creation Time

remains immutable archival metadata associated with the entity.¶

18. No Permanent Sequence Number

ARS-1 does not use:¶

    entity #1
    entity #2
    entity #3

as permanent cryptographic identity.¶

An implementation MAY use database sequences internally.¶

Such sequences MUST NOT become canonical Reference inputs unless explicitly defined by an Application Profile.¶

19. Namespace

Namespace defines the interpretation scope of a Reference.¶

A Namespace MAY represent:¶

    website
    application
    organization
    repository
    tenant
    dataset
    archive

Namespace semantics are application-defined.¶

20. Prefix

Prefix is a Namespace-local semantic series identifier.¶

ARS-1 syntax:¶

    one uppercase letter followed by 1-3 uppercase alphanumeric
    total length: 2 to 4 characters

Recommended length:¶

    2-4 characters

ARS-1 does not define global Prefix semantics.¶

Example:¶

    NX -> Project
    CJ3 -> Writing
    MR -> Media

is valid only when the corresponding Application Profile defines those meanings.¶

21. Prefix Registry

Every deployment SHOULD maintain a Prefix Registry.¶

Within a Namespace:¶

• Prefixes MUST be unique.¶
• A Prefix's semantic meaning MUST remain stable.¶
• A Prefix MUST NOT be silently reassigned.¶
• A retired Prefix MUST NOT be reused for an unrelated meaning.¶
• Historical Prefix meanings MUST remain interpretable.¶

ARS does not maintain a global registry of business meanings.¶

22. Local Reference Grammar

A Local Reference has the form:¶

    <PREFIX>-<PAYLOAD>

Example:¶

    NX-17A492Q

A Local Reference MAY be embedded directly in a URL:¶

    https://example.com/NX-17A492Q

23. Qualified Reference

A system operating across multiple Namespaces MAY use a qualified form:¶

    AEV:NX-17A492Q

An implementation MAY represent an ARS reference using a URI-like notation such as:¶

    ars://AEV/NX-17A492Q

This notation is defined by [ARSURI], which formally registers the ars URI scheme and defines its complete ABNF grammar [RFC5234], encoding rules, case sensitivity, authority/path semantics, and IANA provisional registration.¶

A Local URL does not need to contain the Namespace if the application context already uniquely identifies it.¶

24. Canonical Payload Alphabet

The normative ARS-1 alphabet is:¶

    0123456789ABCDEFGHJKMNPQRSTVWXYZ

Alphabet indices are:¶

    0  -> 0
    1  -> 1
    2  -> 2
    3  -> 3
    4  -> 4
    5  -> 5
    6  -> 6
    7  -> 7
    8  -> 8
    9  -> 9
    10 -> A
    11 -> B
    12 -> C
    13 -> D
    14 -> E
    15 -> F
    16 -> G
    17 -> H
    18 -> J
    19 -> K
    20 -> M
    21 -> N
    22 -> P
    23 -> Q
    24 -> R
    25 -> S
    26 -> T
    27 -> V
    28 -> W
    29 -> X
    30 -> Y
    31 -> Z

The alphabet contains exactly:¶

    32 symbols
    5 bits per symbol

The following characters are excluded:¶

    I
    L
    O
    U

The alphabet is:¶

    ASCII-only
    alphanumeric-only
    canonically uppercase
    URL-safe

Only uppercase letters are permitted in canonical output.¶

25. Human Readability

The alphabet intentionally excludes the visually ambiguous letters:¶

    I
    L
    O
    U

The characters:¶

    0
    1

remain part of the canonical alphabet because ARS-1 requires a pure alphanumeric 32-symbol alphabet.¶

Human-facing interfaces SHOULD use a font with clear differentiation between:¶

    0 / O
    1 / I / L

even though O, I, and L are not valid ARS-1 characters.¶

Canonical References MUST remain uppercase.¶

User-interface input normalization MAY accept lowercase for convenience, but lowercase MUST NOT constitute a canonical Reference representation.¶

26. Variable-Length Payload

Variable-length encoding is a core ARS-1 property.¶

ARS-1 does NOT require every Reference to have the same visible Payload length.¶

Examples MAY include:¶

    CJ3-106
    MR-X4928
    NX-17A492Q
    KX4-7B19Q2

Length MUST emerge from canonical encoding.¶

Implementations MUST NOT introduce random length.¶

Implementations MUST NOT introduce non-canonical visual padding.¶

Application Profiles define the maximum Payload length and public data domain appropriate to their deployment.¶

27. Public Data Domain

An Application Profile defines:¶

    data_bits

The selected Reference Cryptographic Profile MUST provide at least that many Reference Material bits.¶

An Application Profile MUST NOT request more public data bits than its selected Reference Cryptographic Profile can produce.¶

A future Reference Cryptographic Profile MAY provide a larger Reference Material domain.¶

The public data domain is independent from the Root Secret security level.¶

28. Natural Variable-Length Encoding

Let the fixed-width Public Data value be D.¶

The data value is encoded using the ARS-1 Base32 alphabet.¶

Leading zero-valued Base32 symbols MUST be omitted.¶

The canonical rule is:¶

    remove every leading symbol whose alphabet index = 0
    retain at least one symbol

Because alphabet index 0 maps to:¶

    0

leading 0 symbols are omitted from the canonical representation.¶

The all-zero data value is encoded as:¶

    0

and never as an empty string.¶

29. Canonical Encode / Decode Invariants

Let:¶

    Encode(x) = canonical payload
    Decode(s) = underlying data value

A conforming implementation MUST satisfy:¶

    Decode(Encode(x)) = x

and:¶

    Encode(Decode(s)) = s

for every accepted canonical string.¶

A decoder MUST reject non-canonical encodings.¶

For example, if:¶

    ABC

is canonical, then:¶

    0ABC

MUST NOT be accepted as an alternative canonical representation.¶

30. Canonical Reference Record

The canonical Reference record is:¶

    protocol_version
    application_profile_id
    application_profile_version
    reference_cryptographic_profile_id
    reference_cryptographic_profile_version
    namespace
    prefix
    entity_identity
    identity_generation
    reference_key_version
    hardware_profile_id
    hardware_profile_version
    hardware_input

The field order is normative.¶

First Creation Time is intentionally excluded from this record in ARS-1 v1.¶

For all cryptographic operations that reference CanonicalReferenceRecord, the term means the exact binary serialization defined in Section 30.¶

An implementation MUST NOT substitute a JSON, textual, implementation-defined, or otherwise non-normative representation.¶

31. Binary Serialization

All integer values use unsigned big-endian encoding.¶

Canonical field types:¶

    protocol_version
        uint16

    application_profile_id
        uint8 length + UTF-8 bytes

    application_profile_version
        uint16

    reference_cryptographic_profile_id
        uint8 length + UTF-8 bytes

    reference_cryptographic_profile_version
        uint16

    namespace
        uint16 length + UTF-8 bytes

    prefix
        uint8 length + UTF-8 bytes

    entity_identity
        uint16 length + UTF-8 bytes

    identity_generation
        uint32

    reference_key_version
        uint32

    hardware_profile_id
        uint8 length + UTF-8 bytes

    hardware_profile_version
        uint16

    hardware_input
        uint16 length + raw bytes

Variable-length fields MUST contain explicit lengths.¶

Implementations MUST NOT concatenate variable-length fields without explicit boundaries.¶

The resulting byte sequence is the normative CanonicalReferenceRecord.¶

32. String Normalization and Identifier Encoding

The following textual fields MUST be normalized before serialization:¶

    application_profile_id
    reference_cryptographic_profile_id
    namespace
    prefix
    entity_identity
    hardware_profile_id

For ARS-1 core identifiers, the following fields MUST use ASCII bytes only:¶

    application_profile_id
    reference_cryptographic_profile_id
    hardware_profile_id

Prefix is already restricted by the ARS-1 grammar to ASCII uppercase letters and digits.¶

For Namespace, an Application Profile MUST choose exactly one of:¶

    ASCII-only
    Unicode NFC with an explicitly fixed Unicode version

For Entity Identity, the Application Profile MUST define its exact canonical encoding. If Unicode is permitted, the Profile MUST specify the normalization form and Unicode version.¶

Where Unicode NFC is used, the Unicode version is part of the canonical Application Profile definition and MUST NOT change without a new Application Profile Version.¶

Prefix MUST be canonical uppercase after normalization.¶

No implementation may apply locale-dependent case conversion, locale-dependent normalization, or implementation-specific Unicode processing to a canonical field.¶

33. Entity Identity Encoding

Entity Identity serialization MUST be fixed by the Application Profile.¶

If UUID or UUIDv7 is represented as canonical text, the exact textual form MUST be fixed.¶

For example, only one of the following may be canonical:¶

    0198f3c7-7e8d-7c12-a5e1-000000000001

or:¶

    0198F3C7-7E8D-7C12-A5E1-000000000001

The Profile MUST NOT permit both as canonical encodings.¶

34. Reference Salt

Define:¶

    APP_PROFILE_ID_BYTES  = UTF8(application_profile_id)
    PROFILE_ID_BYTES      = UTF8(reference_cryptographic_profile_id)
    NAMESPACE_BYTES       = UTF8(namespace)
    PREFIX_BYTES          = UTF8(prefix)

Then:¶

    SALT_INPUT =
        UTF8("ARS-1/reference-salt") ||
        UINT8(length(APP_PROFILE_ID_BYTES)) ||
        APP_PROFILE_ID_BYTES ||
        UINT16_BE(application_profile_version) ||
        UINT8(length(PROFILE_ID_BYTES)) ||
        PROFILE_ID_BYTES ||
        UINT16_BE(reference_cryptographic_profile_version) ||
        UINT32_BE(reference_key_version) ||
        UINT16_BE(length(NAMESPACE_BYTES)) ||
        NAMESPACE_BYTES ||
        UINT8(length(PREFIX_BYTES)) ||
        PREFIX_BYTES

Then:¶

    SALT =
    SHA256(SALT_INPUT)

For Reference Cryptographic Profile Version 1, the resulting 32-byte digest is the HKDF extraction salt for Reference Material derivation.¶

All variable-length fields in SALT_INPUT MUST use the lengths defined above.¶

The Application Profile Identifier and Application Profile Version are cryptographically bound to the Reference Salt, ensuring that distinct Application Profiles produce distinct salt domains even when they share the same Reference Cryptographic Profile, Namespace, and Prefix.¶

A future Reference Cryptographic Profile MAY define a different salt construction, but MUST use a new Profile Version.¶

35. Reference Material Derivation

For Reference Cryptographic Profile Version 1, first derive the Reference Key using the exact Reference Cryptographic Profile Identifier and Version:¶

    PRK =
    HKDF-Extract(
        salt = UTF8("ARS-1/reference-root-salt"),
        IKM  = RootSecret
    )

    RK =
    HKDF-Expand(
        PRK,
        info = UTF8("ARS-1/reference-root/v") ||
               UINT8(length(PROFILE_ID_BYTES)) ||
               PROFILE_ID_BYTES ||
               UINT16_BE(reference_cryptographic_profile_version) ||
               UINT32_BE(reference_key_version),
        L = 32
    )

Then:¶

    PRK2 =
    HKDF-Extract(
        salt = SALT,
        IKM  = RK
    )

Then:¶

    ReferenceMaterial =
    HKDF-Expand(
        PRK2,
        info = UTF8("ARS-1/public-reference") ||
               CanonicalReferenceRecord,
        L = 32
    )

For this operation, CanonicalReferenceRecord MUST mean the exact binary serialization defined in Section 30.¶

All operations are deterministic.¶

No random nonce or hidden runtime entropy is permitted.¶

Future Reference Cryptographic Profiles MUST define their own complete derivation construction.¶

36. Reference Material Domain Separation

The following domain strings are normative for Reference Cryptographic Profile Version 1:¶

    ARS-1/reference-root-salt
    ARS-1/reference-root/v
    ARS-1/reference-salt
    ARS-1/public-reference
    ARS-1/checksum
    ARS-1/signature/v1

A new cryptographic purpose MUST use a distinct domain-separated label.¶

Profile identifiers and versions are cryptographic context, not substitutes for domain labels. Both MUST be bound exactly where specified by the Profile construction.¶

A future Profile MUST NOT silently reinterpret an existing domain string under the same Profile Version.¶

37. Public Data Extraction

The Application Profile defines data_bits.¶

The Public Data value is the first data_bits of ReferenceMaterial, interpreted in big-endian bit order.¶

An Application Profile MUST specify:¶

    data_bits
    maximum_payload_length

The checksum is 1 symbol (5 bits) as defined by the protocol.¶

The Public Data domain is exactly:¶

    2^data_bits

possible values.¶

Increasing the cryptographic strength of the underlying Reference derivation does not automatically increase the public collision domain.¶

38. Base32 Encoding

For each 5-bit group:¶

    0 -> 0
    1 -> 1
    2 -> 2
    ...
    9 -> 9
    10 -> A
    11 -> B
    12 -> C
    13 -> D
    14 -> E
    15 -> F
    16 -> G
    17 -> H
    18 -> J
    19 -> K
    20 -> M
    21 -> N
    22 -> P
    23 -> Q
    24 -> R
    25 -> S
    26 -> T
    27 -> V
    28 -> W
    29 -> X
    30 -> Y
    31 -> Z

Groups are processed from the most significant bit toward the least significant bit.¶

If the data-bit length is not divisible by 5, the final partial group is padded on the right with zero bits for encoding.¶

A decoder MUST verify that all unused padding bits are zero.¶

39. Payload Length

An Application Profile MUST specify:¶

    data_bits
    maximum_payload_length

The ARS-1 checksum is fixed at 1 symbol (5 bits) as defined in Section 42.¶

The maximum Payload length MUST accommodate the profile's full data domain plus 1 checksum symbol.¶

ARS-1 does not define a universal Payload length.¶

A deployment MAY select a short visual Profile, a larger Profile, or another Profile appropriate to its expected issuance volume and identifier requirements.¶

An Application Profile SHOULD prefer data_bits values divisible by 5 for representation efficiency. Non-multiples of 5 are fully valid and MUST use zero padding as specified in Section 37.¶

40. Collision Guidance

For approximately n independently distributed issued values, the birthday-bound approximation is:¶

    p ~= n^2 / 2^(data_bits + 1)

for sufficiently small probabilities.¶

An Application Profile MUST evaluate its expected lifetime issuance volume against its selected public data domain.¶

The public collision domain is independent from:¶

    Root Secret entropy
    Reference Key size
    Reference Material size
    checksum size

Increasing any of those values does not increase data_bits unless the Application Profile actually exposes additional derived bits.¶

The exact collision probability for n issued References with b = data_bits is:¶

    P(collision) = 1 - e^(-n(n-1) / (2 * 2^b))

For small probabilities, this simplifies to:¶

    P ~= n^2 / (2 * 2^b)

To determine the required data_bits for a target collision probability P_target and expected lifetime issuance volume n:¶

    b >= log2(n^2 / (2 * P_target))

For example, for P_target = 0.5 (50% birthday bound), the exact threshold is:¶

    n ~= sqrt(2 * 2^b * ln 2) ~= 1.1774 * 2^(b/2)

For data_bits = 40, this yields:¶

    n ~= 1.1774 * 2^20 ~= 1.234 * 10^6

meaning approximately 1.234 million independently distributed issued References are needed to reach a 50% collision probability in a 40-bit public data domain.¶

An Application Profile SHOULD use these formulas to select data_bits based on its expected lifetime issuance volume and acceptable collision probability, rather than relying on fixed thresholds.¶

41. Predictability and Enumeration Resistance

Reference derivation is deterministic but MUST NOT be publicly predictable solely from public entity metadata.¶

Without the required secret cryptographic material, observing existing References MUST NOT provide a practical method for predicting Reference Material of unrelated entities under the same Profile.¶

Therefore:¶

    Determinism != Public Predictability

Collision resistance and enumeration resistance are separate security properties.¶

A larger public data domain does not by itself provide authentication or authorization.¶

42. Collision Handling

A collision between two issued References is an issuance failure.¶

Collision handling is an Application-level issuance invariant.¶

An implementation MUST NOT silently resolve a collision using:¶

    random salt
    retry nonce
    database sequence
    current timestamp
    machine identifier
    runtime entropy

A collision MAY be resolved only by an explicit change of canonical profile inputs, such as:¶

    Namespace
    Prefix
    Application Profile Version
    Entity Identity
    Identity Generation
    Reference Cryptographic Profile Version
    Reference Key Version

Such a change creates a distinct canonical Reference context.¶

Applications SHOULD detect collisions before committing a Reference as issued.¶

43. Checksum

ARS-1 defines a deterministic 5-bit hash-derived checksum.¶

For:¶

    canonical_body = PREFIX + "-" + canonical_data

calculate:¶

    digest =
    SHA256(
        UTF8("ARS-1/checksum") ||
        UTF8(canonical_body)
    )

Take the first 5 bits of digest.¶

Interpret them as an integer from 0 to 31, then map through the ARS-1 alphabet.¶

A future Protocol Version MAY define a checksum mechanism with more symbols or a different construction. Such a change requires a new Protocol Version and MUST NOT be introduced under the same Application Profile Version.¶

44. Checksum Placement

The checksum is the final Payload symbol.¶

The canonical structure is:¶

    <PREFIX>-<DATA><CHECKSUM>

The checksum is part of the Public Reference but is not part of canonical_data when computing itself.¶

45. Checksum Verification

A verifier performs:¶

    1. Parse Prefix.
    2. Parse Payload.
    3. Separate the final Payload symbol as checksum.
    4. Treat preceding symbols as canonical data.
    5. Reconstruct PREFIX + "-" + DATA.
    6. Compute SHA256("ARS-1/checksum" || body).
    7. Take the first 5 bits.
    8. Map through the ARS-1 alphabet.
    9. Compare against the supplied checksum.

Checksum verification does not require database access.¶

46. Checksum Security Boundary

The checksum provides a 32-state checksum space. Its random collision probability is 1/32.¶

This value MUST NOT be interpreted as an authentication or cryptographic integrity bound.¶

The ARS-1 checksum is a hash-truncation checksum: it takes the first 5 bits of a SHA-256 digest. This is fundamentally different from algebraic checksums (such as Luhn, ISBN-10, or China ID checksums), which use modular arithmetic to structurally guarantee detection of specific error classes.¶

Because the checksum is hash-derived, it has NO deterministic detection guarantee for any specific error class:¶

• Single-symbol substitution: expected miss probability 1/32, no guarantee¶
• Adjacent-symbol transposition: expected miss probability 1/32, no guarantee¶
• Arbitrary transposition: expected miss probability 1/32, no guarantee¶

Under the standard pseudorandom-function / random-oracle model for SHA-256, a truncated 5-bit checksum of a non-identical input is expected to behave as a uniformly random 5-bit value, yielding an expected collision probability of 1/32 for all error classes. This is a probabilistic expectation, not a proven equality for every specific error transformation. The key distinction is: the checksum has no algebraic structure that would provide deterministic detection of any error class, nor is there evidence of systematic bias toward or against any particular error type.¶

An Application Profile that requires guaranteed detection of specific error classes (e.g., all adjacent transpositions) MUST NOT rely on the ARS-1 checksum alone. Such Profiles SHOULD define additional application-layer validation or select a future Protocol Version with an algebraic checksum mechanism.¶

Therefore the checksum is a:¶

    human-error detector

and NOT:¶

    authentication
    authorization
    signature
    MAC
    proof of provenance
    cryptographic identity

An attacker who knows the algorithm can recompute it.¶

These properties are restated as Hard Invariants 81 and 82 (Section 85). In case of any perceived discrepancy, the Hard Invariants and this Section are intended to be semantically identical.¶

47. Hardware Profile Semantics

A Hardware Profile is identified by:¶

    hardware_profile_id
    hardware_profile_version

A Hardware Profile MUST define an exact deterministic Canonical Challenge construction. The challenge construction MUST be a deterministic function of the canonical Reference context available before hardware_input is produced, together with the Hardware Profile definition.¶

The protocol-visible challenge context MUST include at least:¶

    protocol_version
    application_profile_id
    application_profile_version
    reference_cryptographic_profile_id
    reference_cryptographic_profile_version
    namespace
    prefix
    entity_identity
    identity_generation
    reference_key_version
    hardware_profile_id
    hardware_profile_version

It MUST NOT include hardware_input, because hardware_input is the response-derived output of the Hardware Profile.¶

A Hardware Profile MUST specify the exact byte encoding of its challenge context, challenge derivation algorithm, response algorithm, output truncation rule, and output encoding.¶

A Hardware Profile definition SHOULD provide conformance vectors covering representative equivalent credentials, so that implementers have verifiable behavioral standards for Hardware Credential Equivalence Class claims.¶

A Hardware Credential Equivalence Class MAY be defined by a Hardware Profile. Two hardware credentials MUST be treated as equivalent for ARS reproduction only when the Profile explicitly guarantees that they produce the same deterministic response for every valid canonical challenge.¶

Possessing a physically different device is not, by itself, evidence of hardware credential equivalence.¶

48. Hardware Input Architecture

Hardware is OPTIONAL.¶

ARS-1 defines:¶

    Hardware Profile
          v
    Canonical Challenge
          v
    Hardware Operation
          v
    Deterministic Hardware Response
          v
    Canonical Hardware Input

Possible implementations include:¶

    YubiKey
    TPM
    HSM
    Smart Card
    Secure Enclave
    Secure Element
    other secure hardware

ARS-1 does not depend on any vendor.¶

49. Hardware Profile Contract

A Hardware Profile MUST define:¶

    profile identifier
    profile version
    challenge construction
    hardware operation
    response algorithm
    input encoding
    output encoding
    security assumptions
    recovery procedure
    cryptographic status
    security target

For Reference derivation, a conforming Hardware Profile MUST guarantee:¶

    same profile
    +
    same canonical challenge
    +
    same hardware secret
    =
    same deterministic response

Uncontrolled randomness MUST NOT affect the Reference-derived hardware output.¶

50. Canonical Hardware Input

ARS does not interpret vendor-specific hardware internals.¶

Instead:¶

    Hardware Profile
        v
    deterministic hardware response
        v
    Profile-defined canonical byte representation
        v
    hardware_input

The hardware_input field in the ARS canonical record is exactly that canonical Profile-defined byte representation.¶

The same Hardware Profile Version MUST assign exactly one canonical byte representation to each valid response.¶

51. Hardware Profile Versioning and Agility

Hardware Profile Version MUST be explicit.¶

A future incompatible construction MUST use a new version.¶

A Profile MUST NOT silently change:¶

    challenge construction
    response derivation
    truncation
    output encoding
    hardware algorithm

while retaining the same version.¶

A deprecated or compromised Hardware Profile MUST NOT invalidate already issued References.¶

A deployment MAY stop issuing new References under the deprecated Profile while retaining the Profile for historical reproduction and verification.¶

A Hardware Profile migration MAY change the Hardware Input used by future Reference contexts.¶

It MUST NOT rewrite a historical Reference.¶

52. Hardware Is an Issuance Input, Not a Runtime Resolution Dependency

This is a hard ARS-1 invariant.¶

If hardware participates in Reference generation:¶

    Reference =
    F(
        canonical entity inputs,
        ReferenceKey,
        hardware_input
    )

hardware MAY be required for:¶

    issuance
    reproduction
    migration
    recovery verification

but ordinary Reference Resolution MUST NOT require the hardware to be present after issuance when the application already maintains the Reference -> Entity association.¶

Therefore:¶

    /NX-17A492Q

MUST remain resolvable without an attached hardware device.¶

Loss of issuance hardware MUST NOT invalidate an already issued Reference.¶

53. Hardware Reproduction Modes

A deployment MAY preserve hardware_input as part of the historical Reference record.¶

When hardware_input is retained:¶

    Reference Reproduction

MAY be performed without physical access to the original hardware, provided all other required canonical inputs, Profile information, and key material are available.¶

When hardware_input is not retained, reproduction MAY require the original hardware credential or an explicitly defined recoverable equivalent.¶

An Application Profile using hardware-bound References MUST explicitly document which reproduction mode it uses.¶

54. YubiKey Compatibility

A YubiKey MAY implement an ARS Hardware Profile.¶

A vendor-specific Challenge-Response output becomes the Hardware Profile's deterministic response.¶

ARS cryptographic derivation then incorporates the canonical hardware response through the applicable Reference Cryptographic Profile.¶

ARS-1 does not use vendor-specific hardware cryptography as a replacement for its own Reference derivation architecture.¶

55. User Presence

A Hardware Profile MAY require:¶

    touch
    PIN
    local user approval

These controls determine whether the hardware operation is allowed.¶

They MUST NOT themselves become uncontrolled entropy in Reference derivation.¶

A deterministic Hardware Profile MUST produce the same response for the same canonical challenge and the same hardware secret.¶

56. Hardware Recovery

An Application Profile using Hardware-Bound References MUST define a recovery strategy.¶

Permitted strategies MAY include:¶

    secondary hardware
    recovery key
    secure duplicate hardware
    pre-issued immutable Reference mapping
    stored canonical hardware_input

Loss of the original hardware MUST NOT mutate an already issued Reference.¶

If reproduction is required after hardware loss, the Application Profile MUST define how the necessary reproduction material is recovered.¶

57. Digital Signatures

Digital Signatures are independent from Reference derivation.¶

A signature establishes that a holder of a specific Signing Private Key authorized or signed a specified record.¶

Signatures:¶

• MUST NOT determine the Reference.¶
• MUST NOT alter the Reference.¶
• MAY exist in multiple versions.¶
• MAY use hardware-backed keys.¶
• MAY use classical, post-quantum, or hybrid cryptographic constructions.¶

The cryptographic status of a Signature Profile MUST NOT determine whether an already issued Reference remains valid.¶

58. Signature Key Separation

Signing Private Keys MUST be separate from:¶

    Root Secret
    Reference Key
    Hardware response secret

A signing implementation SHOULD generate its signing key independently.¶

A hardware-backed signing key MAY be stored in:¶

    YubiKey PIV
    TPM
    HSM
    Smart Card
    Secure Enclave

59. Signature Profile

A Signature Profile MUST define:¶

    profile identifier
    profile version
    algorithm
    hash function, if applicable
    key type
    public-key encoding
    signature encoding
    certificate format, if applicable
    canonical message format
    security assumptions
    cryptographic status
    security target

ARS-1 does not prescribe one permanent signature algorithm.¶

Signature Profiles MAY be classified as:¶

    Classical
    Post-Quantum
    Hybrid

A deployment requiring long-term resistance to quantum attacks SHOULD select an approved and currently appropriate post-quantum or hybrid Signature Profile.¶

A future Signature Profile MAY replace an older Profile without changing any associated Public Reference.¶

60. Signature Migration

A Signature Profile MAY be deprecated, superseded, or retired.¶

Deprecating a Signature Profile MUST NOT invalidate:¶

    Entity Identity
    Public Reference
    historical record
    historical content association

A deployment MAY attach a newer signature to the same Reference and state while retaining historical signatures for archival purposes.¶

A migration MAY therefore produce:¶

    Reference
        +-- historical signature
        +-- current signature

without changing the Reference.¶

A cryptographic signature MUST NOT be treated as the permanent identity of the entity.¶

61. Signature Message

A recommended signing context is:¶

    ARS-1/signature/v1
    +
    Namespace
    +
    Reference
    +
    State Root / Record Hash

Signature serialization MUST be specified independently from Reference derivation serialization.¶

A signature MUST NOT be added to the Reference derivation merely to increase perceived security.¶

A change in Signature Profile MUST NOT alter the Public Reference.¶

62. Content Integrity

A Reference does not prove the exact historical contents of an entity.¶

Applications requiring historical integrity SHOULD use:¶

    Content Hash
    State Root
    Merkle Root
    Immutable Object Graph

Conceptually:¶

    Reference
        -> Which durable entity?

    State Root
        -> Which exact historical state?

    Signature
        -> Who authorized the record?

    Authorization
        -> Who is allowed to access or modify it?

These are independent properties.¶

63. Post-Quantum Security Position

ARS-1 is designed so that its core Reference architecture does not depend on classical public-key primitives such as integer-factorization or elliptic-curve discrete-logarithm systems.¶

The ARS-1 Reference Cryptographic Profile Version 1 uses:¶

    256-bit Root Secret
    HKDF-SHA-256
    SHA-256
    256-bit Reference Material

This construction is not based on the classical public-key assumptions targeted by Shor-style attacks.¶

However, ARS-1 MUST NOT claim that any specific cryptographic algorithm is permanently immune to all future quantum or classical cryptanalytic advances.¶

The security target of each Cryptographic Profile is an engineering designation describing the intended security level under the assumptions of the specified primitives.¶

ARS-1 therefore treats the following as separate properties:¶

    classical security
    quantum resistance under current understanding
    long-term cryptographic agility
    archival identity stability

A Profile MAY be cryptographically suitable for current deployment without being treated as permanently safe against all future cryptanalytic advances.¶

64. Post-Quantum Migration Principle

Post-quantum migration MUST occur at the cryptographic Profile layer wherever possible.¶

A deployment MUST prefer:¶

    new cryptographic Profile
            v
    new cryptographic mechanism
            v
    same Entity Identity semantics
            v
    historical References preserved

rather than:¶

    new cryptographic algorithm
            v
    reissue every historical Reference

A Cryptographic Profile migration preserves historical References, but different Cryptographic Profiles are NOT required to derive the same Reference from the same entity context.¶

Historical References remain cryptographically bound to the Profile and key context under which they were originally issued.¶

For example:¶

    Entity E
    Profile v1
    Key v1
        v
    Reference R1

and later:¶

    Entity E
    Profile v2
    Key v2
        v
    Reference R2

MAY produce different References.¶

This does not constitute mutation of R1.¶

R1 remains the canonical historical Reference for the original Reference context.¶

A deployment SHOULD distinguish:¶

    historical Reference preservation

from:¶

    future Reference issuance

When a Cryptographic Profile becomes deprecated or unsafe, the deployment SHOULD:¶

    stop issuing new References under the affected Profile
    preserve historical Profile metadata
    preserve historical References
    introduce a replacement Profile
    migrate signatures or supporting credentials

A cryptographic transition MUST NOT silently reinterpret an existing Reference as though it had been issued under a different Profile.¶

65. Reference Resolution

Reference Resolution means:¶

    Reference -> Entity

Resolution is an application-state operation.¶

A system MAY resolve a syntactically valid and checksum-valid Reference to:¶

    existing entity
    retired entity
    tombstone
    missing entity

depending on application policy.¶

Checksum validity alone does NOT establish that an entity exists.¶

Reference Resolution MUST NOT require a particular cryptographic Profile unless the application explicitly needs cryptographic reproduction or verification.¶

66. Reference Reproduction

Reference Reproduction means:¶

    Canonical Reference Inputs
    +
    Reference Cryptographic Profile
    +
    Reference Key
    +
    Hardware Input, if required
            v
    Reference

A conforming implementation MUST reproduce the exact canonical Reference.¶

Reproduction is cryptographic.¶

Resolution is application-state based.¶

The two operations MUST NOT be conflated.¶

67. Reference Verification Levels

A verifier MAY operate at multiple levels.¶

    Prefix syntax
    Payload alphabet
    separator
    canonical casing
    maximum length

    checksum

    canonical Base32 representation
    canonical Prefix
    canonical Payload form

    Root Secret
    Reference Cryptographic Profile
    Application Profile
    canonical entity inputs
    Hardware Input, where required

    Reference -> Entity

68. Public Reference vs Authorization

A valid Reference MUST NOT imply:¶

    permission
    ownership
    authentication
    authorization

Applications MUST enforce authorization independently.¶

Knowledge of a Reference MUST NOT itself grant privileged access.¶

69. Permanent Non-Reuse

Once an ARS Reference has been issued:¶

    delete entity
    trash purge
    import
    migration
    restore
    rename
    move
    reparent
    cryptographic Profile migration
    signature migration
    hardware Profile migration

MUST NOT release the Reference for reassignment.¶

A retired Reference MUST NOT be reassigned to an unrelated entity.¶

70. Semantic URL Independence

Semantic routes MAY change:¶

    /lab/zephyr
        v
    /zephyr
        v
    projects/zephyr
        v
    zephyr.example.com

The ARS Reference remains stable:¶

    NX-17A492Q

Therefore:¶

Semantic URL = current information architecture. ARS Reference = durable identity locator.¶

71. Canonical URL

When an ARS Reference is embedded in a canonical URL:¶

• Prefix MUST be canonical uppercase.¶
• Payload MUST use the canonical ARS-1 alphabet.¶
• The separator MUST be exactly one ASCII hyphen.¶
• The Reference itself MUST NOT require percent-encoding.¶
• Lowercase representations MUST NOT constitute a separate canonical identity.¶

Example:¶

    https://example.com/NX-FC5RT0TC0

A future cryptographic Profile MUST NOT require changing the canonical URL representation of an already issued Reference.¶

72. Export / Import

A complete portable export MUST preserve all information necessary to reproduce existing References.¶

At minimum:¶

    Root Secret secure backup
    Identity Generation
    Namespace
    Prefix Registry
    Entity Identity
    First Creation Time
    Application Profile Version
    Reference Cryptographic Profile Version
    Reference Key Version
    Hardware Profile and Version, if used
    stored canonical hardware_input, if retained by policy
    Application Profile
    Public Reference

A complete archival export SHOULD also preserve:¶

    historical Signature Profiles
    historical signatures
    Signature Profile Versions
    cryptographic Profile metadata
    Profile security targets
    Profile status history

Where a Hardware Profile requires an external hardware credential for reproduction, the export policy MUST document how that credential is preserved, duplicated, escrowed, or otherwise recovered.¶

Imports MUST preserve historical References.¶

A correct export/import cycle MUST satisfy:¶

    Original Reference
    =
    Imported Reference

for identical canonical identity context, applicable Profile definitions, and required key material.¶

73. Key Rotation

Key rotation MUST NOT rewrite historical References.¶

Example:¶

    Reference Key v1
        v
    historical References

    Reference Key v2
        v
    new References

Historical References MUST retain their Reference Key Version.¶

Old key material SHOULD remain protected for as long as cryptographic reproduction of historical References is required.¶

Changing Reference Key Version MAY affect newly issued References, but MUST NOT silently alter historical ones.¶

74. Cryptographic Downgrade Resistance

Cryptographic Profile selection for new Reference issuance MUST be governed by authenticated local deployment policy.¶

An untrusted caller, request field, import record, or network input MUST NOT be able to select a Deprecated or Retired Cryptographic Profile when the deployment policy requires a stronger Active Profile.¶

A deployment MUST define a minimum acceptable Cryptographic Profile for new issuance. The effective issuance policy MUST be evaluated before Reference derivation.¶

Historical reproduction is a distinct operation and MAY use the historical Cryptographic Profile and Reference Key Version originally bound to the Reference, provided the required historical material is available and the deployment explicitly permits such reproduction.¶

Therefore:¶

    new issuance
        v
    current authenticated policy
        v
    minimum acceptable Profile

    vs.

    historical reproduction
        v
    historical Profile context
        v
    exact historical Reference

A cryptographic migration MUST NOT be interpreted as permission for an untrusted caller to request a weaker Profile.¶

A conforming implementation MUST fail closed when a requested Profile is unknown, unsupported, below the configured issuance security floor, or otherwise disallowed by policy.¶

75. Cryptographic Profile Deprecation

Every Reference Cryptographic Profile SHOULD have an explicit lifecycle status:¶

    Active
    Deprecated
    Retired

A Profile MAY become:¶

    Deprecated

when a stronger or more appropriate Profile is available.¶

A Profile MAY become:¶

    Retired

when continued issuance under that Profile is no longer acceptable.¶

Retirement MUST NOT invalidate historical References.¶

Historical Profiles MUST remain identifiable to conforming archival software for as long as historical Reference reproduction is required.¶

A deployment MAY prohibit creation of new References under a Deprecated or Retired Profile while retaining the Profile for historical verification.¶

A Deprecated or Retired Profile MUST NOT be silently substituted with another Profile.¶

76. Cryptographic Profile Migration

A cryptographic migration is the controlled introduction of a new Cryptographic Profile for future issuance or reproduction.¶

A migration MUST identify:¶

    source Profile
    target Profile
    migration status
    effective issuance boundary
    historical preservation policy
    reproduction policy
    signature migration policy, if applicable
    hardware migration policy, if applicable

A migration MUST preserve:¶

    Entity Identity
    historical Reference
    historical Profile Version
    historical Reference Key Version
    historical Reference mapping

A migration MAY issue a new Reference for the same durable Entity when the Application Profile explicitly permits multiple Reference contexts.¶

If multiple References exist for one Entity, the Application Profile MUST define which Reference is:¶

    current canonical Reference
    historical Reference
    alias
    migration successor

No migration process may silently replace an existing historical Reference.¶

77. Protocol Versioning

Protocol Version MUST identify the exact ARS construction.¶

For example:¶

    ARS-1

defines this specification.¶

A future:¶

    ARS-2

MAY change:¶

    serialization
    KDF architecture
    encoding
    checksum architecture
    Profile architecture
    Reference grammar

ARS-2 MUST NOT silently reinterpret an ARS-1 Reference.¶

Historical ARS-1 References remain ARS-1 References.¶

Cryptographic Profile changes that preserve the ARS-1 protocol architecture SHOULD use Profile Versioning rather than forcing a protocol-version change.¶

78. Application Profile Requirements

Every deployment SHOULD define:¶

    Namespace
    Application Profile ID
    Prefix Registry
    Entity Identity format
    First Creation Time policy
    Reference Cryptographic Profile ID
    Reference Cryptographic Profile Version
    Reference Key Version policy
    Application Profile Version
    data_bits
    maximum_payload_length
    Checksum policy
    Hardware Profile
    Signature Profile
    URL policy
    backup policy
    key rotation policy
    export/import policy
    collision policy
    hardware recovery policy, if applicable
    cryptographic migration policy

An Application Profile MAY be stricter than ARS-1.¶

It MUST NOT weaken ARS-1 deterministic or canonical requirements.¶

79. Example Application Profile

ARS-1 does not mandate any specific real-world Application Profile.¶

An illustrative Profile MAY define:¶

    Namespace:
        EXAMPLE

    Application Profile ID:
        PersonalArchive

    Application Profile Version:
        1

    Reference Cryptographic Profile ID:
        ARS1-REF

    Reference Cryptographic Profile Version:
        1

    data_bits:
        40

    maximum_payload_length:
        9

The checksum is 1 symbol (5 bits) as fixed by the protocol.¶

Example Prefix Registry:¶

    NX:
        Project

    CJ3:
        Writing

    MR:
        Media

    KX4:
        Experience

The above is illustrative only.¶

ARS-1 itself does not require 40-bit data, nine-symbol maximum Payloads, or any particular Prefix Registry.¶

80. Formal Test Vector

The following vector is normative.¶

It uses a test-only Application Profile and the ARS-1 Default Reference Cryptographic Profile Version 1.¶

All values below use the final ARS-1 alphabet:¶

    0123456789ABCDEFGHJKMNPQRSTVWXYZ

    Protocol Version:
    1

    Application Profile ID:
    Example-40

    Application Profile Version:
    1

    Reference Cryptographic Profile ID:
    ARS1-REF

    Reference Cryptographic Profile Version:
    1

    Namespace:
    AEV

    Prefix:
    NX

    Entity Identity:
    0198f3c7-7e8d-7c12-a5e1-000000000001

    Identity Generation:
    1

    Reference Key Version:
    1

    Hardware Profile ID:
    NONE

    Hardware Profile Version:
    1

    Hardware Input:
    empty

    Root Secret:
    00112233445566778899aabbccddeeff
    00112233445566778899aabbccddeeff

    data_bits:
        40

    maximum_payload_length:
        9

    00010a4578616d706c652d3430000108415253312d524546
    00010003414556024e58002430313938663363372d376538642d
    376331322d613565312d30303030303030303030303100000001
    00000001044e4f4e4500010000

    d017c2784b7727608283929f06497086cdbd680c9d7ffa73260ecbe68ed1a34f

    4152532d312f7265666572656e63652d73616c740a4578616d706c
    652d3430000108415253312d5245460001000000010003414556024e58

    4a75371f00fffe18a072faaaae941c18905cab120649a37a6106974243ca1aad

    6ddcc2caeddf82ea5f843ec7b48c145b4de5ee1a64f1bc0cd96d19579529f052

    6ddcc2caed

    DQEC5JQD

    NX-DQEC5JQD

    e66740721579883487c3e7afd8d2525f8aed5c04e7152f37868929579dc44661

    NX-DQEC5JQDW

81. Negative Verification Vector

The following Reference is derived from the Section 79 final Reference (NX-DQEC5JQDW) by corrupting the checksum symbol from W to X.¶

The following Reference MUST fail checksum verification:¶

    NX-DQEC5JQDX

because the normative checksum does not match the supplied checksum symbol.¶

A decoder MUST also reject non-canonical Base32 representations containing unnecessary leading zero-valued symbols.¶

For example, a data value canonically represented as:¶

    ABC

MUST NOT accept:¶

    0ABC

as an equivalent canonical Reference payload.¶

82. Independent Implementation Requirement

A conforming implementation SHOULD pass:¶

    canonical serialization vectors
    Reference Cryptographic Profile vectors
    Reference Key vectors
    Reference Salt vectors
    Reference Material vectors
    Base32 vectors
    variable-length encoding vectors
    checksum vectors
    negative verification vectors
    Hardware Profile vectors
    Signature Profile vectors
    Profile migration vectors
    Profile identity separation vectors
    Cryptographic downgrade rejection vectors
    Hardware challenge construction vectors
    Hardware credential equivalence vectors

At least two independently implemented implementations SHOULD be cross-tested.¶

Recommended implementation languages include:¶

    Rust
    TypeScript / JavaScript
    Go
    Python

Cross-language outputs MUST match exactly.¶

Independent implementations SHOULD test at least one implementation in a memory-safe systems language and one implementation in a separate runtime or language ecosystem.¶

83. Reference Implementation

A production deployment SHOULD maintain a minimal reference implementation whose purpose is:¶

    canonical serialization
    Reference Cryptographic Profile handling
    key derivation
    Reference Material derivation
    Base32 encoding / decoding
    checksum generation / verification
    Reference reproduction
    Profile verification
    test-vector generation

The test-vector generator SHOULD be treated as a build-time or verification tool, not as part of the runtime trust model.¶

Normative vectors SHOULD be generated from the reference implementation and independently verified before every protocol release.¶

A reference implementation MUST NOT silently fall back to a different cryptographic Profile when a requested Profile is unavailable.¶

84. Encoder / Decoder Property Tests

A conforming implementation SHOULD test at least:¶

    Decode(Encode(x)) = x
    Encode(Decode(s)) = s

for a large corpus of generated values.¶

The corpus SHOULD include:¶

    all-zero values
    single-bit values
    boundary values
    values with leading zero Base32 groups
    maximum profile values
    random values

Decoders SHOULD reject:¶

    invalid alphabet characters
    lowercase output when canonical uppercase is required
    non-canonical leading-zero encodings
    invalid padding bits
    empty payloads
    payloads exceeding profile limits
    unknown checksum profiles
    unknown cryptographic Profiles
    unknown Profile Identifier + Version pairs
    malformed version fields
    unsupported Unicode version declarations
    invalid Hardware Profile challenge constructions

Implementations SHOULD test that historical References remain reproducible after introducing a new Cryptographic Profile or Signature Profile.¶

85. Security Considerations

A Secure ARS deployment MUST:¶

• use a CSPRNG for Root Secret generation¶
• use the minimum entropy required by the selected Reference Cryptographic Profile¶
• protect Root Secret material¶
• use an explicitly selected Reference Cryptographic Profile ID and Version¶
• use explicit Profile Versioning¶
• separate cryptographic purposes¶
• canonicalize all serialized inputs¶
• fail closed on malformed input¶
• preserve Reference Key Versions¶
• preserve Reference Cryptographic Profile Versions¶
• preserve historical References¶
• avoid hidden runtime entropy¶
• avoid silent collision fallback¶
• avoid silent cryptographic algorithm substitution¶
• enforce an authenticated minimum Profile policy for new issuance¶
• reject cryptographic downgrades for new issuance¶
• preserve Profile metadata required for historical reproduction¶

For Reference Cryptographic Profile Version 1, implementations MUST:¶

• use a 256-bit Root Secret¶
• use HKDF-SHA-256 as specified [RFC5869]¶
• produce a 256-bit Reference Key¶
• produce a 256-bit Reference Material value¶

Implementations SHOULD also:¶

• zeroize sensitive intermediate material where practical¶
• minimize secret lifetime in memory¶
• avoid secret exposure in diagnostics¶
• protect encrypted backups¶
• audit key rotation¶
• audit cryptographic Profile migration¶
• test import/export reproducibility¶
• test historical Reference reproduction¶

86. Root Secret Compromise Response

A Root Secret compromise is a critical security incident. It affects the enumeration resistance property (Section 40) but does NOT affect Reference identity stability.¶

Historical References remain canonical and MUST NOT be invalidated, reassigned, or reissued. The compromise is a confidentiality failure of the derivation secret, not an integrity failure of the Reference.¶

87. Profile Identifier Uniqueness

Profile Identifier uniqueness is scoped to the applicable ARS Profile Registry (Section 84.3). Within a Registry, each Identifier MUST be unique and permanent.¶

The following Profile Identifiers are defined by this specification and registered in the ARS Canonical Profile Registries (Section 84.3):¶

• ARS1-REF: Reference Cryptographic Profile Identifier (Version 1 defined in Section 9)¶
• NONE: Hardware Profile Identifier (no hardware)¶

These protocol-defined identifiers are reserved and MUST NOT be redefined by Application Profiles or deployments.¶

A deployment MAY define its own Profile Identifiers. When two independent deployments need to interoperate, they SHOULD exchange and verify complete Profile definitions before interoperation. Cross-deployment reproduction or verification requires explicit Profile alignment.¶

A deployment SHOULD maintain an internal registry of all Profile Identifiers it uses. The internal registry SHOULD follow the same field model as the ARS Canonical Profile Registries (Section 84.3).¶

88. ARS Profile Registry Model

ARS-1 defines a formal Profile Registry architecture consisting of three Canonical Profile Registries, each governing a distinct Profile type:¶

    ARS-1
    |
    +-- ARS Reference Cryptographic Profile Registry
    |     Governs: Reference Cryptographic Profiles (Section 9)
    |
    +-- ARS Signature Profile Registry
    |     Governs: Signature Profiles (Section 58)
    |
    +-- ARS Hardware Profile Registry
          Governs: Hardware Profiles (Section 46-50)

Application Profile Identifiers are deployment-scoped and are NOT governed by a Canonical Registry. Cross-deployment Application Profile alignment is the responsibility of the interoperating deployments (Section 84.2).¶

    https://github.com/Juwan-Hwang/ARS-1

89. Canonical Profile Registry -- Initial Entries

90. IANA Considerations

ARS-1 v1.0 does NOT request IANA to create any new registries.¶

The ARS Canonical Profile Registries (Section 84.3, 84.4) are maintained as GitHub-maintained canonical registries within the ARS-1 specification repository.¶

If future protocol evolution requires IANA-managed registries, the following migration path is defined:¶

    GitHub Canonical Registry
        v
    Internet-Draft (IETF or independent submission)
        v
    IANA Registry creation request

At that point, the IANA-managed Registry would succeed the GitHub Canonical Registry as the authoritative source. Existing GitHub Registry entries would be migrated as initial IANA Registry entries. The (Identifier, Version) permanence rules (Section 84.3.1, 84.3.4) would carry over to the IANA Registry without modification.¶

This section is informative for v1.0. A future ARS specification version MAY make IANA-related sections normative.¶

91. Hard Invariants

ARS-1 MUST satisfy all of the following:¶

1. Identical canonical inputs under the same Reference Cryptographic Profile ID and Version produce identical References.¶
2. Reference derivation contains no hidden randomness.¶
3. Root Secrets are generated with a CSPRNG.¶
4. The selected Cryptographic Profile defines the required Root Secret security level.¶
5. Reference derivation uses an explicit Cryptographic Profile ID and Version.¶
6. Cryptographic purposes use independent derivation domains.¶
7. Entity Identity is immutable.¶
8. First Creation Time is immutable archival metadata when used by the Application Profile.¶
9. First Creation Time is not a Reference derivation input in ARS-1 v1.¶
10. Permanent identity does not depend on mutable titles or content.¶
11. Sequence numbers are not permanent identity unless explicitly profiled.¶
12. Payload length may naturally vary.¶
13. ARS-1 does not prescribe one universal Payload length.¶
14. Application Profiles define their own data-bit and length policies.¶
15. The ARS-1 alphabet contains exactly 32 ASCII alphanumeric symbols.¶
16. The ARS-1 alphabet contains no punctuation or other symbols.¶
17. Hardware is optional.¶
18. Hardware Profiles are vendor-neutral.¶
19. Hardware-derived Reference inputs are deterministic.¶
20. Hardware input is explicit canonical input.¶
21. Digital signatures do not determine the Reference.¶
22. Signature Profiles are independent from Reference derivation.¶
23. Signature Profiles are replaceable without rewriting historical References.¶
24. Checksum is deterministic.¶
25. Checksum is not cryptographic authentication.¶
26. Reference validity is not authorization.¶
27. Reference validity is not content integrity.¶
28. Historical References never change.¶
29. Historical References are never reused.¶
30. Export/import preserves References.¶
31. Key rotation does not rewrite historical References.¶
32. Prefix semantics are Namespace-local.¶
33. Prefix meanings cannot be silently reassigned.¶
34. Collision fallback cannot introduce hidden randomness.¶
35. A detected collision is an issuance failure unless canonical inputs are deliberately changed.¶
36. Canonical URLs are deterministic.¶
37. Canonical Base32 representations are unique.¶
38. Independent conforming implementations produce identical References.¶
39. Cryptographic algorithms are public.¶
40. Secret cryptographic material is never embedded in source code.¶
41. Protocol Version, Application Profile ID/Version, Reference Cryptographic Profile ID/Version, Reference Key Version and Hardware Profile ID/Version are distinct identity/version dimensions.¶
42. Signature Profile Version does not affect Reference derivation.¶
43. Cryptographic Profile changes MUST be explicit.¶
44. A deprecated Cryptographic Profile MUST NOT silently reinterpret historical References.¶
45. Historical References remain valid after Cryptographic Profile migration.¶
46. A Signature Profile may be migrated without changing the associated Reference.¶
47. Canonical References use uppercase output.¶
48. The ARS-1 alphabet excludes I, L, O and U.¶
49. The ARS-1 alphabet is exactly: 0123456789ABCDEFGHJKMNPQRSTVWXYZ¶
50. An empty canonical Payload is never valid.¶
51. Leading zero-valued Base32 symbols MUST be omitted in canonical encoding.¶
52. Variable-length canonical fields MUST use explicit length encoding.¶
53. Reference Salt construction MUST use the normative length-delimited serialization, including Application Profile Identifier and Version.¶
54. CanonicalReferenceRecord in cryptographic operations MUST mean the exact binary serialization defined in Section 30.¶
55. Hardware loss MUST NOT mutate an already issued Reference.¶
56. Stored canonical hardware_input MAY permit reproduction without physical access to the original hardware.¶
57. Reference derivation MUST NOT depend on a signature.¶
58. A future Cryptographic Profile MUST NOT silently alter an existing Profile Version.¶
59. A future Signature Profile MUST NOT silently alter an existing Signature Profile Version.¶
60. A future Hardware Profile MUST NOT silently alter an existing Hardware Profile Version.¶
61. Cryptographic migration MUST preserve historical Reference identity.¶
62. Reference Resolution and Reference Reproduction are distinct operations.¶
63. Protocol evolution SHOULD prefer Profile Versioning when the existing ARS architecture remains semantically valid.¶
64. ARS-1 MUST NOT require a particular classical public-key algorithm for its core Reference construction.¶
65. ARS-1 MUST preserve cryptographic agility as a protocol design property.¶
66. Different Reference Cryptographic Profiles are not required to derive the same Reference from the same entity context.¶
67. Historical References remain bound to their original Reference Cryptographic Profile and Reference Key context.¶
68. Cryptographic Profile migration MUST NOT silently replace a historical Reference.¶
69. Cryptographic Profile security targets are engineering designations, not permanent guarantees of future security.¶
70. A cryptographic Profile MUST NOT be treated as permanently immune to future quantum or classical cryptanalysis solely because it is designated as active.¶
71. A Profile Identity is the exact ordered pair of Profile Identifier and Profile Version.¶
72. Application Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to Reference Salt derivation.¶
73. Reference Cryptographic Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to key derivation.¶
74. New Reference issuance MUST obey the deployment's authenticated minimum Cryptographic Profile policy.¶
75. Historical reproduction MAY use the historical Cryptographic Profile context and MUST NOT silently substitute a different Profile.¶
76. ARS-1 core Profile identifiers are ASCII-only.¶
77. Unicode-enabled canonical fields MUST have a Profile-defined normalization form and fixed Unicode version.¶
78. Hardware Profile challenge construction MUST be deterministic and fully specified.¶
79. Hardware credential equivalence MUST be explicitly defined by the Hardware Profile when equivalence is claimed.¶
80. Hardware Profile output truncation and encoding MUST be explicitly versioned.¶
81. The checksum provides a 32-state checksum space. Its random collision probability is 1/32. This MUST NOT be interpreted as authentication or cryptographic integrity.¶
82. The ARS-1 checksum is a hash-truncation checksum. It has NO deterministic detection guarantee for any specific error class. Under the pseudorandom-function / random-oracle model, the expected miss probability for all error classes is 1/32.¶
83. Root Secret compromise does NOT invalidate historical References. Historical References remain canonical and do NOT need to be reissued. Reference identity stability is preserved.¶
84. Root Secret compromise causes loss of enumeration resistance for the compromised Root Secret domain, including ALL Reference Key Versions derived from that Root Secret. This loss is permanent and irrecoverable. To restore enumeration resistance for new issuance, the deployment MUST generate a NEW, independent Root Secret. Key Version rotation under the SAME Root Secret is NOT sufficient.¶
85. Reference Salt (Section 33) provides domain separation for public inputs but does NOT provide additional secret entropy. Salt-based domain separation does NOT limit the scope of a Root Secret compromise.¶
86. A deployment MAY adopt per-Namespace or per-Prefix Root Secrets for stronger isolation. ARS-1 v1 does NOT mandate a single-Root-Secret model.¶
87. Hardware Profile field order in canonical serialization is hardware_profile_id before hardware_profile_version, consistent with all other Profile field ordering.¶
88. A Profile Identifier MUST NOT include a version suffix. Version is always a separate field.¶
89. The ordered pair (Identifier, Version) is permanent and MUST NOT be reused for a different Profile definition.¶
90. ARS-1 defines three Canonical Profile Registries: Reference Cryptographic Profile Registry, Signature Profile Registry, and Hardware Profile Registry.¶
91. A Retired Profile MUST NOT be reactivated to Active status.¶
92. The Identifier prefix "ARS1-" is reserved for protocol-defined Profiles. Third-party Identifiers MAY use other prefixes. Deployments MUST NOT allocate Identifiers beginning with "ARS1-" without explicit protocol authorization.¶

92. Long-Term Security Position

ARS-1 separates:¶

    stable archival identity

from:¶

    current cryptographic assumptions

The intended long-term model is:¶

                    Stable Reference
                           |
            +--------------[U+253C]--------------+
            |              |              |
       Reference       Signature      Hardware
       Cryptography      Profile        Profile
            |              |              |
            v              v              v
         Versioned      Versioned      Versioned
         Profile        Profile        Profile

Therefore:¶

    Reference
        v
    does not need to change

when:¶

    current hash/KDF construction
          v
    future stronger construction

or:¶

    Classical Signature
          v
    Post-Quantum Signature

or:¶

    Hardware Profile v1
          v
    Hardware Profile v2

The purpose of cryptographic agility is not to predict the future algorithm.¶

The purpose is to ensure that ARS does not need to predict it.¶

A Cryptographic Profile migration may produce a different Reference for a newly derived Reference context. This is expected and does not constitute mutation of the historical Reference.¶

93. Security Model

ARS should be understood as four independent layers:¶

    Layer 1 -- Identity
        Entity Identity
        Identity Generation

    Layer 2 -- Reference
        Reference Cryptographic Profile ID / Version
        Root Secret
        Reference Key
        Reference Material
        Public Reference

    Layer 3 -- Integrity / Provenance
        State Root
        Content Hash
        Digital Signature
        Signature Profile

    Layer 4 -- Access Control
        Authentication
        Authorization
        Policy

No layer may implicitly replace another.¶

Cryptographic algorithm migration SHOULD occur within the relevant layer and SHOULD NOT require cross-layer identity mutation.¶

94. Final Architecture

                             ARS-1
                               |
                       Application Profile ID/Version
                               |
                 +-------------[U+2534]-------------+
                 |                           |
           Canonical Entity            Optional Hardware
               Context                     Input
                 |                           |
                 +-------------[U+252C]-------------+
                               v
                  Reference Cryptographic
                  Profile ID/Version
                               v
                        Reference Key
                               v
                        Reference Material
                               v
                        Public Data Bits
                               v
                     Canonical Base32 Encoding
                               v
                           Checksum
                               v
                        Public Reference
                               |
                               v
                               URL

Separately:¶

    Signature Profile
            v
    Digital Signature
            v
    Reference + State Root

Separately:¶

    State Root
        v
    Historical Content Integrity

95. Final Principle

ARS-1 is not a prettier UUID [RFC4122].¶

It is a:¶

deterministic archival reference language for durable digital entities.¶

Its defining visual property is:¶

Prefix + naturally variable-length cryptographic Payload.¶

It deliberately does not mandate one universal Payload length.¶

Its defining technical property is:¶

The same complete canonical conditions, applicable Cryptographic Profile, and same key material always produce exactly the same Reference across independent implementations.¶

Its defining security property is:¶

The algorithms are explicit and versioned. Security derives from high-entropy protected secret material and standardized cryptographic constructions rather than from obscurity.¶

Its defining long-term property is:¶

Cryptographic assumptions may evolve without requiring the reassignment of historical References.¶

Its defining extensibility property is:¶

Reference Cryptographic Profiles, Signature Profiles, and Hardware Profiles are independently versioned and replaceable.¶

A future cryptographic transition SHOULD therefore look like:¶

    Old Profile
        v
    Historical References remain unchanged

    New Profile
        v
    Future Reference contexts / signatures / hardware mechanisms

rather than:¶

    Old cryptography
        v
    Reissue every historical Reference

The protocol is designed not to predict which cryptographic assumptions will remain valid forever.¶

It is designed so that ARS can survive when those assumptions change.¶

For ARS-1:¶

    Stable Identity
            +
    Cryptographic Agility
            +
    Canonical Serialization
            +
    Variable-Length Encoding
            +
    Permanent Non-Reuse
            +
    Portable Reproduction
            +
    Independent Verification

constitute the protocol's long-term archival model.¶

Profiles MAY define external lifecycle metadata such as expiration, revocation, or tombstone state. Such metadata MUST NOT alter the canonical Reference unless explicitly defined by a new protocol version.¶

ARS-1 itself remains general-purpose and does not mandate any particular application-level Payload length or cryptographic signature algorithm.¶

ARS URI Scheme

The ars URI scheme is formally specified by [ARSURI] -- ARS URI Scheme -- A URI Scheme for ARS-1 References, v1.0-rc2, available at <https://github.com/Juwan-Hwang/ARS-1/blob/main/spec/ARS-URI.md>.¶

The ars URI scheme is registered as a provisional URI scheme in the IANA URI Schemes Registry (<https://www.iana.org/assignments/uri-schemes>), following the registration guidelines of [RFC7595] and the URI syntax of [RFC3986].¶

The ars URI scheme defines the syntax ars://<namespace>/<local-reference> for representing ARS-1 References as URIs. It includes the complete ABNF grammar, authority/path semantics, case sensitivity rules, percent-encoding rules, canonicalization, resolution semantics, and IANA provisional registration template.¶

Conforming ARS-1 implementations are NOT required to support the ars URI form. The canonical ARS-1 Reference representation is always the Local Reference form defined in Section 21. Internationalized Resource Identifiers [RFC3987] are out of scope for ARS-1 References, which use a restricted ASCII-compatible character set.¶

Acknowledgments

The ARS-1 protocol and its 23 independent implementations provided the foundation for this specification.¶

Author's Address