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]
