Identity
A composite verdict every enrollment.
Every peer joining a Beacons fleet is verified through three independent layers — and either all three pass, or the peer never sees a route. Setup keys are not a concept here.
1 · OAS — resolve the DID
The peer presents a did:oas:<ns>:<kind>:<id>. The coordinator resolves it via the OAS resolver chain (DHT, MARS, hosted Locks resolver, configured fallbacks). Resolution returns the peer's identity document — verification keys, lineage proofs back to a root, attestations.
- 11 entity kinds — hmr, mhr, enr, agent, tool, skill, workflow, model, dataset, service, agent:instance
- Lineage walks bounded by MAX_GENERATION (default 16)
- Fleet declares trusted roots — descendants accepted
- Offline-verifiable. No vendor lookup required.
peer.did = "did:oas:acme:agent:scribe-7" resolved: parent did:oas:acme:agent:librarian grandparent did:oas:acme:hmr:jr depth 3 trusted-root? did:oas:acme:hmr:jr ✓ verification: method ed25519 key z6Mk…hRT9
coordinator → peer: nonce 0x9d8c… (32 bytes, fresh) scope did:oas:acme:fleet:prod peer → coordinator: signed = Ed25519.sign(nonce ‖ scope, peer.key) coordinator: Ed25519.verify(signed, peer.verification_key) ✓ challenge_time_within_skew: 740ms ✓
2 · AEGIS — challenge-response
Once the DID is resolved, the coordinator issues an AEGIS challenge: a fresh nonce that the peer signs with its lineage signing key. The signature is verified against the verification method published in the peer's identity document. This proves possession of the OAS lineage key.
- Ed25519 signatures, fresh nonces, clock-skew tolerance
- Human peers chained from Ory Kratos session
- Agent peers: direct challenge, no session UI
- Replays detected and logged to the audit chain
3 · Arsenal — capability token
After identity is proven, the coordinator verifies that the peer holds an Arsenal Capability Token (ACT) with scopebeacons:fleet:join for this specific fleet. ACTs are issued by the organization's Arsenal broker (or a hosted Locks broker) and bound to the peer's DID, the fleet ID, a time window, and optional constraints.
- Time-windowed — typically minutes to hours
- Revocable — revocation propagates in seconds
- Rate-limit and IP-allowlist constraints supported
- Capability lineage tracked — who issued what to whom
act = {
iss: did:oas:acme:hmr:jr,
sub: did:oas:acme:agent:scribe-7,
scope: "beacons:fleet:join",
fleet: did:oas:acme:fleet:prod,
iat: 1722390000,
exp: 1722390000 + 420,
cons: { rate: "60/s" },
sig: ed25519:…
}
→ signature valid ✓
→ scope matches ✓
→ time window open ✓
→ not revoked ✓Composite
A peer is admitted if and only if…
- 01Its `did:oas` resolves to a valid OAS identity document.
- 02Its lineage chain terminates at a fleet-trusted root.
- 03Its AEGIS challenge response is cryptographically valid.
- 04Its Arsenal Capability Token is valid, unrevoked, and scopes `beacons:fleet:join` for this fleet.
- 05The fleet's ENR governance permits this peer's entity kind.
- 06The peer presents a transport capability the coordinator can match.
If any check fails, enrollment is rejected and the failure is logged in the fleet's audit chain — with the reason, the DID, the coordinator region, and a hash of the challenge that failed. See audit chain.