Delegation

ARK has no central authority handing out guarantees. It has namespaces handed down, and at each step the recipient takes on the promise. arkhe's ledger is a record of that chain.

flowchart TD
    RA["NAAN holder<br/><small>e.g. a national institute</small>"]
    RA -->|"carves out /x9"| I1["Organisation A"]
    RA -->|"carves out /y2"| I2["Organisation B"]
    RA -->|"/z1 delegated onward"| EX["External minter"]
    I1 --> C1["repository system"]
    I1 --> C2["bulk import job"]
    I2 --> C3["repository system"]

Two things travel down that chain, and they are not the same thing:

• the namespace — which names you may create, and
• the commitment — what you promise about what you created.

Reach

Every principal — a person signing in, or a system holding a key — carries a reach, and it is an attribute of the registration. Nothing in a request or a token can widen it.

system	Every NAAN. The operator of the registry — the side that hands namespaces out
naan	Everything under one NAAN. The organisation holding it
manager	One organisation. Optionally pinned to a single shoulder

Nobody can grant more than they hold. A NAAN administrator cannot create a system administrator; an organisation administrator cannot create a principal for another organisation.

Why the shoulder is not in the request

arklet took {naan, shoulder} from the request body and authorised at NAAN level only, so a misconfiguration — or a lie — reached another organisation's namespace. arkhe derives the shoulder from the principal, which closes that and handles routing among many organisations at the same time.

Shoulder states

A namespace, once handed out, cannot be taken back. So "held but not usable" and "no longer minting" have to be states rather than deletions.

stateDiagram-v2
    [*] --> reserved: created with --reserve
    [*] --> active: created
    reserved --> active
    reserved --> delegated
    active --> delegated
    active --> retired
    delegated --> active
    delegated --> retired
    retired --> [*]: existing ARKs keep resolving

retired has no way back. Reviving a retired namespace cannot rule out that something outside used one of its names in the meantime — and re-issuing a name that someone else already used is exactly what NR forbids.

delegated requires a minter to point at: if minting happens elsewhere, a request to mint must be told where to go. arkhe answers 307 with the location and does not proxy — proxying would mean that a lost response could leave an ARK minted over there that nobody here knows about.

Organisations come and go

• Succession — an organisation merges into another. The shoulders move; the ARKs do not change at all. What changes is who mints next.
• Departure — an organisation leaves but continues to exist. Minting stops; resolution continues forever, and the targets can be redirected to the organisation's own resolver so that nothing further is asked of us.

Both are covered in Succession and departure.