And that is where being clear of who is the principal in this whole flow is
important:
* if this the people or org that build the agent? And that is why you talk
about a legal person and it being an authorization grant.
* Or is it the resource owner as defined, without mentioning the term, in
1.1 Problem Statement of draft-wei-aic-jwt-00: who delegated the authorization,
which operations were authorized, under which constraints the Agent may run,
how long the authorization is valid, and who is accountable for the Agent's
actions?
Because these two are not the same party, and the draft uses principal for both.
Once we take the RFC 7523 grant framing you proposed, the specs you are relying
on place the roles differently than the draft does:
1. RFC 6749 has no subject. The agent is the client_id (aka the OAuth
client) and the authorizing party is the resource owner. There is no subject
role in 6749 at all. So "the DA is issued by the principal with the agent as
subject" is already off-model and the agent's slot is client_id, not subject.
2. The moment we bring in RFC 7523 / 8693, subject resolves to the
principal, not the agent. RFC 6749 §1.2 defines an authorization grant as a
credential representing the resource owner's authorization. So if the DA is a
§1.2 grant presented per 7523, the party it represents (the grant's sub) is the
resource owner. And RFC 8693 is explicit about the fact that the subject_token
is the party on whose behalf the action is taken, the actor_token is the acting
party. The agent is the actor. It is never the subject. So "agent as subject"
puts the agent in the wrong slot in both specs you cite.
3. Which of my two bullets is the principal?
* If §1.5 (and your reply) mean a natural or legal person accountable
for the agent, that is the operator/deployer.
* But §1.1's "who delegated the authorization" is the resource owner.
Those coincide only when the agent's operator is the resource owner. In the
enterprise-agent / end-user-data case (for example the OBO scenario in §1.6),
they diverge: the accountable legal person is the enterprise, the resource
owner delegating access to their mailbox/photos/account is the end user. If the
DA is signed by the principal-as-operator and asserts the agent as subject,
then the resource owner's authorization is not represented anywhere in the
token while this is the one thing a §1.2 grant is defined to carry.
What you need to resolve is:
* If the DA's subject is the resource owner (consistent with 6749 §1.2 and
7523), then "natural or legal person accountable for the agent" is the wrong
definition of principal, and "agent as subject" is wrong . The agent is the
actor/client.
* If the DA's subject really is the agent, then the DA is not carrying a
resource owner's authorization at all. It is carrying the agent's own identity
and declared capabilities. That is client self-identification, and we already
have a mechanism being standardized for exactly that: CIMD
(draft-ietf-oauth-client-id-metadata-document), where the client_id resolves to
the client's own. That is a different thing from a §1.2 authorization grant,
and so §1.6's claim that this produces the OBO case does not hold, because
there is no slot for the resource owner's consent.
My suggestion would be to pin principal === resource owner and place the agent
as actor/client. Then if the intent is instead to describe the agent's own
identity and capabilities, that is the CIMD lane, not an authorization grant.
And if you also need the operator / accountable legal person bound, that is a
second party that needs its own representation, not the grant subject. Again
CIMD defines in §4.3 the Relationship with software_statement.
Jeff
Jean-François “Jeff” Lombardo | Amazon Web Services
Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada
From: Jijie Wei <[email protected]>
Sent: September 4, 2026 11:37 AM
To: oauth <[email protected]>
Cc: Lombardo, Jeff <[email protected]>
Subject: RE: [EXT] [OAUTH-WG] Re: For review/discussion: externalizing the
token issuance decision to a policy decision point
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
contenu ne présente aucun risque.
Jeff,
Thank you -- fair point: the first message should have named JAR
and PAR before describing the DA. One distinction drives everything
below.
AIC-JWT is the OAuth-facing profile of an X.509 design. Both share one
artifact: a Delegation Authorization (DA) -- a JWT issued by the
principal (a natural or legal person), with the agent as subject, that
binds the agent's capabilities, a nonce, and an expiry. In OAuth
terms, the DA is used as an authorization grant, not as an
authorization request. RFC 6749 (Section 1.2) defines an authorization
grant as a credential representing the resource owner's authorization,
and RFC 7523 profiles JWTs for use in this role. The agent presents
the DA at the token endpoint as a jwt-bearer grant (RFC 7523 Section
2.1); the AS validates the signature, audience, expiry, nonce, and
that the requested capabilities are within the signed grant, and
determines which principal keys it trusts for this purpose.
On JAR and PAR -- agreed: they are the request path, and we propose
nothing there. A Request Object carries the authorization request
parameters (RFC 9101 Section 2.1); PAR pushes that request to the AS
and returns a request_uri (RFC 9126). The DA is the authorization
grant presented afterwards, not the authorization request itself.
On the ceiling -- I agree with your distinction between the
principal-signed bound and the AS/PDP decision. The DA establishes an
upper bound on the authority that may be issued for the agent. AS
logic and an externalized PDP may narrow that authority for a
particular request instance, exactly as you describe. "May narrow,
never broaden" constrains the authority bound; it does not replace AS
policy or PDP discretion below that bound.
On obligations, including the extra-scope question you put to Omri:
duties and conditions (logging, notification, trust elevation,
transformation of already-authorized data) attach below the authority
ceiling and do not themselves expand it. An obligation requiring an
action or resource that the principal did not authorize is different:
adding the corresponding scope would be authority expansion by another
name, so the correct behavior is a new authorization request backed by
a new grant or consent (your option b). The only middle case is an
extra scope that merely re-expresses authority already contained in
the signed grant; then it may be introduced below the ceiling. Closing
the ceiling at the principal's signature is what prevents obligation
creep from becoming authority creep.
On determinism across vocabularies -- the honest answer is that there
is a boundary. AIC capabilities are structured (scheme + capability
identifiers + typed parameters), so within one capability scheme,
subset and equivalence are byte-deterministic. "Photos/Write" at B and
"Storage/WriteObject" at C are different vocabularies; no signature
model can decide their semantic equivalence, and ours does not claim
to. A vocabulary mapping may translate an already-authorized
capability into another protocol or service vocabulary, but it cannot
introduce authority absent from the signed grant.
One sentence, for the record: the DA moves the upper bound of issuance
authority to the principal's key; everything OAuth already does --
JAR, PAR, AS risk narrowing, PDP evaluation, and obligations -- still
happens below that bound. If useful, I can pin commits and paste
runnable vectors covering these cases, including the B-to-C example.
Best,
Jijie Wei
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
