advancedPhase 7

Call Chaining (R1 acts as Agent to R2)

Resource 1 needs data from Resource 2 to fulfil the agent's request, so R1 acts as an agent: it has its own agent identity and signing key. It routes the downstream request to the person server named by the ps claim of the upstream auth token — first for a person token for R2, then for the auth token. There is no delegation chain claim: -11 removed act, and the PS holds the chain because it authorizes every hop.

§ Call Chaining

GET https://api.example/data200

The agent accesses R1 with its AS1-issued auth token (sig=jwt — the auth token is the signing credential).

That token's ps claim names the person's PS. It is what R1 will route the downstream request to.

R1 needs data from R2 to fulfil the request, and it will act as an agent to get it.

1 / 6

speed

Step 1: Agent → R1 with AS1 auth token → R1 needs R2

Request / response

GEThttps://api.example/data

Host

api.example

Signature-KeyAAuth?

sig=jwt;jwt="eyJhbGciOiJFZERTQSIsImtpZCI6ImFzMS1rZXktMSIsInR5cCI6ImFhLWF1dGgrand…

Signature-InputAAuth?

sig=("@method" "@authority" "@path" "signature-key");created=1700000000;alg="ed2…

SignatureAAuth?

sig=:UFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB…

HTTP Signaturescheme=jwt

Covered Components

@method

@authority

@path

signature-key

Signature Base

"@method": GET

"@authority": api.example

"@path": /data

"signature-key": sig=jwt;jwt="eyJhbGciOiJFZERTQSIsImtpZCI6ImFzMS1rZXktMSIsInR5cCI6ImFhLWF1dGgrand0In0…"

"@signature-params": sig=("@method" "@authority" "@path" "signature-key");created=1700000000;alg="ed25519"

Signature-Key Header

sig=jwt;jwt="eyJhbGciOiJFZERTQSIsImtpZCI6ImFzMS1rZXktMSIsInR5cCI6ImFhLWF1dGgrand0In0…"

Signature-Input Header

sig=("@method" "@authority" "@path" "signature-key");created=1700000000;alg="ed25519"

Auth Token (Agent→R1)aa-auth+jwt

Header

{"alg":"EdDSA",
"kid":"as1-key-1",
"typ"?Token type identifier. aa-agent+jwt = Agent Token, aa-person+jwt = Person Token, aa-resource+jwt = Resource Token, aa-auth+jwt = Auth Token:"aa-auth+jwt"
}

Payload

{"iss"?Issuer — who created and signed this token:"https://as.example",
"dwk"?Discovery Well-Known — the metadata document name for key discovery (e.g. aauth-agent.json, aauth-person.json):"aauth-access.json",
"aud"?Audience — which party should accept this token:"https://api.example",
"jti"?JWT ID — unique identifier for this token (replay detection, audit, revocation):"5aba3c5f-0509-4483-a99e-394c0a2b1313",
"ps"?The person's Person Server. In a resource token, the iss of the person token the resource verified. In an auth token, the PS the person is represented by — and where an intermediary routes a downstream request.:"https://ps.example",
"sub"?Subject. In an agent token, the agent identifier. In a person, resource or auth token, the person's directed identifier — opaque, unique within the issuer. Identity is the pair (iss, sub); a sub from one issuer MUST NOT be matched against a record established under another.:"8f14e45fceea167a5a36dedd4bea2543",
"cnf"?Confirmation — proof-of-possession claim binding this token to a key:{"jwk"?JSON Web Key — the public key bound to this token:
},
"scope"?Authorized scope/permissions granted by this token:"read",
"iat"?Issued At — Unix timestamp when the token was created:1776222894,
"exp"?Expiration — Unix timestamp after which the token is invalid:1776226494
}

sig: wuhpIWVGWe2kNxVtCXDsYgp0ngxD7Hth…