Raidiam
Book a working session

Evidence: Wherever it runs

Where an agent runs decides what it can prove. What it can prove decides what it keeps.

Our agents run in different places. What should each place be allowed to do?

Deployment evidence The attester's narrowing table on this estate

  • 1Claim on this page
  • 3Artefacts behind them
  • 1Reads you can run here

Back to Wherever it runsEvery claim on this site

What the attester checks before it vouches

Fourteen checks, in the order the attester runs them.

The Tarnbrook attesterA reference implementation. The first check that fails ends the request, under its own name.

  1. The request

    1. Check 1Nonce
    2. Check 2Instance key
    3. Check 3Key proof

  2. The agent

    1. Check 4Agent resolves
    2. Check 5Member mark
    3. Check 6Attester named
    4. Check 7Runtime permitted

  3. The release

    1. Check 8Release record
    2. Check 9Publisher signature
    3. Check 10Release digest
    4. Check 11Artefact digest

  4. The runtime evidence

    1. Check 12Evidence kind
    2. Check 13Evidence verified

  5. The copy

    1. Check 14Copy bit
A client attestationThe copy's key, its assurance and its ceiling.
Each check, by the name the code answers with
  1. Check 1nonceIssued here, used once.
  2. Check 2instance_keyThe copy's own key.
  3. Check 3instance_popSigned over the nonce.
  4. Check 4agent_resolvesReaches the Tarnbrook anchor.
  5. Check 5agent_markA current member mark.
  6. Check 6attester_namedNames this attester.
  7. Check 7hosting_permittedThis runtime is permitted.
  8. Check 8release_recordFetched from the publisher.
  9. Check 9release_signatureThe publisher's signature.
  10. Check 10release_digestThe referenced digest.
  11. Check 11artefact_digestThe signed artefact.
  12. Check 12evidence_kindThis runtime's kind.
  13. Check 13evidence_verifiedAn SVID, or an enrolment.
  14. Check 14bit_allocatedA bit on the signed list.

Checks 7, 12 and 13 turn on the runtime, and the other eleven ask the same of every copy.

The workload domain and the workstation

The workload domain and SPIRE

SPIRE issues each copy a short lived SVID. At check 13 the attester verifies its chain, finds its SPIFFE ID on the agent's record, and checks it is bound to the copy's key over the nonce. The result is attested.

The managed workstation

At check 13 the attester verifies an enrolment token from the workforce platform, so a person the enterprise knows stood the copy up. The result is asserted.

What the platform checks before it admits a copy

Fourteen names, in the order the API platform runs them.

The API platformAdmits a copy on attest_jwt_client_auth. A failed check refuses the copy under its own name.

  1. The attester

    1. Check 1Attester chain
    2. Check 2Attester mark
    3. Check 3Attester named

  2. The attestation

    1. Check 4Signature
    2. Check 5Type
    3. Check 6Subject
    4. Check 7Lifetime

  3. The proof of possession

    1. Check 8Proof signature
    2. Check 9Audience
    3. Check 10Challenge
    4. Check 11Used once

  4. The copy

    1. Check 12Copy live
    2. Check 13List readable

  5. The identity

    1. Check 14Auth method
A token that states the assuranceGranted inside the attester's ceiling.
Each check, by the name the code answers with
  1. Check 1attester_chainResolves to a pinned anchor.
  2. Check 2attester_markA current attester mark.
  3. Check 3attester_namedNamed by the agent.
  4. Check 4attestation_signatureSigned by the attester.
  5. Check 5attestation_typeA client attestation.
  6. Check 6attestation_subjectAbout this agent.
  7. Check 7attestation_expiredInside its lifetime.
  8. Check 8pop_signatureSigned by the attested key.
  9. Check 9pop_audienceFor this platform.
  10. Check 10pop_challengeA current challenge.
  11. Check 11pop_replayedUsed once.
  12. Check 12instance_stoppedIts bit is live.
  13. Check 13instance_status_unreadableThe list is readable.
  14. Check 14auth_method_not_permittedResolves with attest_jwt_client_auth.

The platform believes an attestation only after it resolves the attester's own chain, verifies the statement, and checks a proof signed with the copy's key.

Where the platform finds the attester

It then reads the copy's bit on the attester's signed list of copies, so one copy can be stopped while the others carry on.

The attester's table, in full

Every row the attester declares, and what each one lets through.

Workload

An SVID

records.read
Kept
records.annotate
Kept
transfer.status
Kept
transfer.initiate
Kept
review.submit
Kept
Reached here
Batch Reviewer

Workstation

An enrolled person

records.read
Kept
records.annotate
Withheld
transfer.status
Withheld
transfer.initiate
Withheld
review.submit
Withheld
Reached here
Analyst Companion

Workstation

Enrolled, hardware key

records.read
Kept
records.annotate
Kept
transfer.status
Kept
transfer.initiate
Withheld
review.submit
Withheld
Reached here
By no copy

Workstation

Enrolled, app attestation

records.read
Kept
records.annotate
Kept
transfer.status
Kept
transfer.initiate
Withheld
review.submit
Withheld
Reached here
By no copy

The attester can only cut.

The working behind this figure

No copy on this estate reaches the two hardware rows: the attester here holds no hardware root, and it refuses app attestation evidence.

What this page proves

Each claim, its label and the artefacts behind it.

The vouched key set of a recognition statement

Not observed on this tenant

The design requires that the statement about a recognised root vouches only the keys that root publishes. On this tenant the statement about a self managed entity whose organisation holds no key vouches one key, the tenant's hosted entity signing key, which the subject does not hold. In the entity generated model the subject holds its own private key and Connect does not receive it. The key this statement vouches is the tenant's hosted entity signing key, which Connect adds by product behaviour rather than from anything the subject supplied.

Lifecycle stage
Keys
Lives in
Raidiam Connect
Checked by
Test E11
Artefacts cited
3

This claim on the evidence page

The working

What the figures above leave to words.

The claim above rests on the subject holding its own private key, and on this tenant one case does not hold it. For a self managed entity whose organisation holds no key of its own, the statement about that entity vouches one key the subject never supplied: the tenant's hosted entity signing key, which Connect adds by product behaviour. The four runtimes on this page are governed the same way whichever key signs for them, and the exception is recorded here rather than left for a reader to find on the security page. Not observed on this tenant

Where the authority comes from

The authority governs the identity. Where a copy is attested, the copy generates its own key where it runs and proves it holds it.

Ten terms
anchor
The root entity of a trust domain whose key a consumer pins from configuration.
authority
A Connect entity that publishes signed subordinate statements, marks and policy about the entities it governs.
trust domain
The set of entities that chain to one anchor.
entity configuration
The self signed statement an entity publishes at its own identifier.
subordinate statement
The statement a superior signs about a subordinate: keys, policy, marks.
trust mark
The signed projection of an active accreditation, with a status endpoint.
envelope
The set of authorization detail types and grant types an authority permits an agent to request. The registered ceiling.
resolve
Walk the chain from a leaf to a pinned anchor and fold the policy.
pin
The anchor key a consumer holds in configuration, written at deploy time, as the pair of anchor identifier and key.
recognition
The governed act by which an authority becomes a superior of an entity that already publishes its own configuration, minting nothing.

Check it against the running estate

Every surface this use case touches, and the host that answers for it.

The workload domain and SPIREworkloads.agents.showcase.raidiam.io The attesterattest.agents.showcase.raidiam.io The API platformapi.agents.showcase.raidiam.io The Tarnbrook cataloguecatalogue.agents.showcase.raidiam.io Quillon's host stands in for a third partyquillon-production-ff3b.up.railway.app

Which runtimes do you have, and which assurance would you accept for which envelope?

Ninety minutes, on the shape of your estate: which systems resolve first, which anchor each pins, and which key each party holds.

Book a working session

Explore further