FAQ

Is this a specification?

No. It is a working profile with a list of recommendations for the people who write the specifications. The code exists so the recommendations are backed by something that runs rather than by argument.

Do I have to use UMA to use these ideas?

No. The guides name each role before naming any product or protocol, and several of the primitives stand alone — operation-bound grants and indivisible single-use are useful whatever issues your tokens. UMA is the part that gives the owner an authority of her own, which is hard to reproduce without something shaped like it.

Does this replace my policy engine?

No, and the two compose. A policy engine decides; this profile is about whose policy the decision expresses. You will probably want an engine inside the authorization server described here. See Policy engines.

Do I need solo.io, Istio, or Kubernetes?

None of them. The lab uses agentgateway, kgateway and Istio ambient because they filled the roles cleanly and are worth showing, but every guide states the role first and the product second. The compose stack runs the same code with none of that, and the same enforcement core also runs embedded in the resource with no gateway at all.

Is this not just CIBA, or asynchronous authorization?

No, and the difference is the whole point. Backchannel authentication reaches a person who is not at the browser, which is a genuine and necessary capability — this profile needs it too. What it does not change is whose policy decided to ask her, what she is allowed to say back, or whether a relationship exists afterwards that she can revoke. With a backchannel approval she has a button; what she does not have is authority. See OAuth 2.0, CIBA and GNAP.

We already let an admin consent on the organisation's behalf. Is that not enough?

For data the organisation owns, yes — and enterprise-managed agent authorization, Cross App Access and ID-JAG handle that case well. The case here is the one where no admin anywhere has standing: Alice is a customer of the brokerage rather than an employee, her advisor works somewhere else again, and the data is hers. See compared to agent identity work.

Does the owner have to be online?

That is the case the design exists for. Her policy answers the ordinary requests while she is asleep. Requests on an ask-me tier are held — the negotiation survives the authorization server being deleted and the database failing over, which make k8s-chaos demonstrates by doing both mid-request.

What happens the first time an agent she has never seen arrives?

It pends, whatever the tier. First contact is a decision about the relationship rather than about the request, so she is asked once. After that her existing terms cover it, and she is only asked again for operations her policy says she must approve personally.

How many agents can this handle?

Connections are stored one row per agent with no ceiling, and her policy names tools rather than agents, so an agent she has never seen is not a gap in her configuration. Each gets its own approval, terms, ledger trail and revocation.

Is the agent identity part required?

No. An agent can be pseudonymous, in which case it is its key and that key's thumbprint is the connection handle. Identity buys continuity across key rotation and something true to display to the owner. It never becomes an authorization input — the verifying key is always the one named in the grant.

Can I use this in production?

Not as it stands, and the repository says so in several places. It ships fixed development credentials, one authorization server per resource server, and no signing-key rotation. What it is for is deciding whether the shape is right before you build your own.

Who is behind it?

A collaboration between Nick Gamb and Eve Maler, who co-authored the UMA specifications. Apache-2.0, and the repository is the whole of it.