Omri, Roland, Iman, all,
The thread has converged on the ceiling question -- what bounds the
issued token, who sets that bound, and whether a PDP may cross it. I
can offer a deployed data point from the other direction: an
authorization server where the ceiling of the issuance decision is
already externalized -- not to a PDP, but to a principal-signed
artifact. The AS remains the decision maker; what it may decide within
is fixed by a signature rather than by a policy call. It lands
squarely on the "may narrow, never broaden" invariant, and it may be
a useful reference for the ceiling discussion.
The model is specified in draft-wei-aic-jwt-00 (with the same data
model in the X.509 profile, draft-wei-aic-identity-cert). At issuance
the agent presents a Delegation Authorization (DA) -- a JWT signed by
the principal's own key -- via the RFC 7523 jwt-bearer grant. The
authorization server validates that DA (principal signature, nonce
uniqueness, and that the requested capabilities are a subset,
capability-level and parameter-level, of what the principal signed) and
only then signs the outer token. The spec states the bound directly:
the AS MUST NOT sign the outer token without a valid principal-signed
DA (Section 10.2).
So the ceiling in this model is not the AS's local policy and not a PDP
verdict -- it is established by the principal's signature, and it is
closed cryptographically rather than configurationally. The AS may
issue a subset of the signed grant and may shorten the lifetime (we
clip to min(requested, cap), with a one-hour deployment default and a
fixed 24-hour ceiling), but it cannot add authority the principal did
not sign. A PDP, where one is present, chooses within that
principal-signed ceiling; it never widens it. That is the same
ceiling-versus-recommendation split Iman describes, with the ceiling
anchored one step earlier -- at the principal's key rather than at the
AS's grant validation.
Two points that may matter for the profile's open questions:
* On affordability at issuance rates (Section 4 of the issuance
draft): this decision is a local signature verification plus a
nonce lookup, not an external round trip. In our deployment it
measures in the low microseconds per issuance at the engine level,
with sustained issuance in the several-thousand-certificates-per-
second range under tuned conditions. A closed, signature-defined
ceiling is cheap to enforce at issuance rates; the cost question
is really about the PDP call, which this arrangement keeps off
the critical issuance path.
* On the token-exchange binding: our Section 10.4 uses RFC 8693 and
requires the exchanged token to carry the intersection of the
actor's capabilities with the subject's grants -- the same
narrowing invariant applied at exchange time, across the seam your
exchange draft targets. We have the X.509-to-JWT bridge path
implemented and the full subject/actor exchange specified, and I
would be glad to compare notes on the intersection semantics.
The profile is also graded rather than all-or-nothing, which may matter
for the "is this in scope / who needs it" question: a lightweight
consumer deployment can omit the DA entirely and let the AS sign
directly from recorded consent, while an enterprise deployment pins the
ceiling to the principal's signature. Same wire shape, different
placement of the decision.
Happy to elaborate on the validation sequence or the subset semantics
on-list or off-list, whichever is more useful.
Best,
Jijie Wei
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
