A model quoting one of these carries our sentence into a conversation we are not in, so the first sentence is the whole design. Each page then evidences it against the spec, the registry or a runnable block — and links up to delegated authority.
Not on this system today. contract.sign is registered and reserved, and no grant in production carries it — agents propose, and a named human signs. That is a design position rather than a temporary limitation, and it will change on the registry page first if it ever changes.
The verifier refuses, and the refusal names the constraint that was exceeded rather than returning a generic failure. The chain can be entirely valid and the action still refused — those are different results and the wire format represents them differently.
Fetch the issuer’s public JWKS, verify the signature, walk the delegation chain, and evaluate the mandate against what is being asked. You hold no credential from us to do any of it; the key is public and the whole check runs on your side.
The human at the root of the chain. Every grant is issued by a principal, and following the chain up terminates at a person rather than at an organization or a service account — which is the reason the chain travels with the assertion instead of being looked up.
It voids that grant and everything beneath it, immediately, for any party that resolves at use time. A counterparty who cached the assertion continues to hold a valid signature until expiry — so revocation is not yet a substitute for a short expiry, and we say so on the page rather than in a footnote.
No, and you probably already have one. OAuth answers whether a client may call an API. This answers whether the party behind that call was authorised, by whom, and within what limits — a question that only becomes interesting once the caller is an agent acting for someone else.
Exactly the scopes and limits written into that grant, until its expiry, and nothing more. An attacker cannot widen it, because a widened chain fails the attenuation check at every verifier — the blast radius is set when the grant is issued rather than when the breach is discovered.
They answer different questions and neither writes the other’s truth. FlashyOS answers what is happening; Flashy ID answers who may act. Running the coordination layer without the identity layer works until an agent has to prove something to a party outside your organization.
Arithmetic, not policy. A grant is checked against its parent at issue time and again at every verification, so a chain that widens anywhere fails as a whole rather than at the offending link. An agent can mint children freely and none of them can exceed it.
Authentication proves who you are. Authorization proves what you may do inside one system. Delegated authority proves on whose behalf you are acting and within what limits — the only one of the three that has to survive leaving the building, and the only one that gets interesting when the actor is an agent.
Shorter than you are comfortable with, because expiry is currently doing the work revocation cannot. Until cross-organization revocation propagates, a cached assertion stays valid until it expires — which makes the expiry your real blast-radius control rather than a hygiene setting.
No, and that is the point. The signing keys are public, the wire format is published, and the whole verification runs on your side against a cached JWKS. If verification required a relationship with us, the network would be exactly as large as our customer list.