Raidiam
Book a working session

Evidence: Across the boundary

They bring claims and evidence. You decide the effective authority.

A partner outside our control runs its own agents under its own root. What do we hold about them, and who can withdraw it?

  • 5Claims on this page
  • 15Artefacts behind them
  • 10Reads you can run here

Back to Across the boundaryEvery claim on this site

Known limitation

Not observed on this tenant The authority resolves both chains and answers, and that answer is the one drawn here. On this tenant the API platform and the workforce platform cannot act on it for the Holdings Reader. Larkspur's root is bound to the Aldercross scheme, so each platform asks its own authority whether it recognises that scheme, that question returns a server error, and each platform refuses the Holdings Reader before a tool is reached. What this page draws is the authority's resolve, not a platform admission of either agent.

On this estate

Reference implementation

A partner's agent, bounded by your rules

You issued the Holdings Reader nothing. You hold one record about Larkspur: the recognition, and its ceiling.

What your platform checks when a partner's agent arrives

Your policy on the recognition hop

Not your organisation

Larkspur Partners

  • Its own rootLarkspur's root
  • Its agentHoldings Reader
  • What it carriesaldercross.accredited.agent

Larkspur issued this identity and holds its key. Nothing you decide changes that.

Your trust decision

  1. Walk the chain to your anchor

    DerivedThe chain runs from Holdings Reader through Larkspur's root to the Tarnbrook anchor, which you pin.

  2. Read the marks it carries

    DeclaredYou recognise the issuing authority through tarnbrook.recognised.scheme, so you read this mark.

  3. Fold your policy on that hop

    DerivedOn that hop tarnbrook.external.reader sets authorization_details_types subset_of to records.read, transfer.status.

  4. Compare what you require with what it holds

    DerivedThe Tarnbrook API platform requires tarnbrook.external.reader on Larkspur's root, which your recognition carries, and aldercross.accredited.agent on the agent. This agent holds it. The platform then asks its own authority whether it recognises the scheme that issued that accreditation, and on this tenant that question answers a server error, so it refuses before a tool is reached.

Your organisation

The Tarnbrook API platform

It asks for 1:

  • records.readread_records

    Inside your ceiling

Effective authority, as your authority answers it

records.read

Three bounds, and two of them are yours. You set the ceiling on the hop and the mark you require on their root. The third is the scheme's accreditation, which you read because you recognise the scheme.

Your platform walks the chain from the Holdings Reader through Larkspur's root to your own anchor, checks each signature upward, reads the scheme accreditation the agent carries, and folds the ceiling you set on the hop where you recognised Larkspur. It then asks its own authority whether it recognises the Aldercross scheme. On this tenant that question returns a server error, so the platform refuses the Holdings Reader before a tool is reached.

The design requires that each trust domain's anchor is signed by its own key. On this tenant both anchors sign with one federation key, and both authorities sign with one authority key. The two trust domains stay separated by entity identifier and by governance record, and a consumer's pin is the pair of entity identifier and key, so a chain to the wrong anchor is refused on the issuer. Cryptographic separation is absent: the holder of the shared key can mint a statement in either anchor's name, and on this tenant that holder is Raidiam in both cases. Not observed on this tenant

The statement about a recognised root is where a consumer learns which key that root signs with. The keys page carries what this tenant vouches on that statement, on a row of its own. Not observed on this tenant

The two bounds on that path

Two bounds act on that path and each is set independently. The ceiling on the hop says what an agent under Larkspur's root can be granted. The mark the platform requires of the agent says whose agents it answers at all. A request can clear one and fail the other.

When the Tarnbrook platform reaches the Holdings Reader it walks the chain through Larkspur's root to its own anchor, checks each signature upward, folds the policy, reads the leaf's marks, and asks the Aldercross authority for the current status of the scheme's mark. The query is a form post of the mark itself, and the answer is signed by the issuing authority. Use case 6 revokes that accreditation, and the lifecycle page states what the status answer bounds on this tenant. Observed

What this page proves

Each claim, its label and the artefacts behind it.

One organisation under two authorities

Observed

The same identity is admitted in two trust domains by two chains that end at two anchors, separated by entity identifier and governance record.

The rest of the statement

One hosted entity configuration names both authorities and carries a mark from each domain.

Lifecycle stage
Discover
Lives in
Raidiam Connect
Checked by
Test verification:5
Artefacts cited
7

This claim on the evidence page

The working

What the figures above leave to words.

What it means for the business

Larkspur Partners and Quillon Software each run their own agents under their own root. You hold one record about each: the recognition, and the ceiling on that hop. You issue their agents nothing.

Where the authority comes from

Each side pins its own anchor and folds its own policy. A named person at your organisation revokes the recognition, and a named officer at the scheme revokes the accreditation. Each is one governed record. Revoking the recognition takes the partner's root off your authority's list within seconds, and a consumer holds its last resolve for at most its configured resolution lifetime. What revoking the accreditation reaches on this tenant is on the lifecycle page.

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.

The three identifiers the ceiling is made of

Each row below links the artefact behind it, read on the wire on the date printed beside it. The instrument on the claim page reads none of these: it works out what the estate declaration permits, and says Derived under its answer.

The same identity is admitted in two trust domains by two chains that end at two anchors, separated by entity identifier and governance record. One hosted entity configuration names both authorities and carries a mark from each domain. Observed

The claim page says the plain form of this: they get only what you allowed. The instrument on the claim page prints the role and its operator, and these are the three names behind them.

tarnbrook.external.reader is a role your own organisation declares. It is one of the three kinds of external admission the Tarnbrook authority recognises, beside the two division ceilings, and it is the kind both partner roots on this figure carry. A recognised root carries exactly one kind, and the kind it carries sets the ceiling on its hop, so the mark that admits a party and the ceiling it gets are one record rather than two.

authorization_details_types is the openid_relying_party metadata parameter that lists the kinds of request an agent may make. The two this role permits are records.read and transfer.status.

subset_of is a metadata policy operator defined by OpenID Federation (open standard) rather than a Raidiam invention. An authority publishes a metadata policy in the statement it signs about a member below it, and the operator says how that policy meets what the member asserts about itself. subset_of keeps the values that appear in both, so an agent that asserts more than the ceiling resolves to the intersection, and one that asserts less keeps its own shorter list. The same role sets token_endpoint_auth_method with one_of, which is the other narrowing operator: the leaf still chooses its method, from the set the ceiling allows.

Two operators, and they bound an agent differently

The instrument on the claim page draws the Tarnbrook hop, where tarnbrook.external.reader sets authorization_details_types with subset_of and intersects the row with what the leaf asserts. The scheme's own row is the other operator: aldercross.accredited.agent sets the same parameter with value, which replaces what the leaf asserts. Both rows carry records.read and transfer.status. A member that resolves an agent through the Aldercross anchor therefore reads the sector ceiling outright, and a member that resolves the same agent through its own recognition hop reads the intersection.

Check it against the running estate

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

Larkspur's host and gateway stands in for a third partylarkspur-production.up.railway.app Quillon's host stands in for a third partyquillon-production-ff3b.up.railway.app The Tarnbrook API platformapi.agents.showcase.raidiam.io Raidiam Connectweb.directory.showcase.raidiam.io

Which partner should be your second trust domain, and what ceiling would you set?

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