Peter, thanks for sending this to the list.
With several cross-domain delegation proposals now in flight across OAuth and
WIMSE, I'd suggest we stop evaluating them thread by thread and instead review
each against a common set of requirements. That is what
draft-reece-wimse-cross-org-delegation was written for: R1–R9 state,
mechanism-independently, what cross-organizational delegation of authority to
agents has to provide. I'd propose the group use it — or an amended version the
group prefers — as the standard rubric, and that solution proposals arrive with
a self-assessment against it.
Applied to this proposal, as a worked example:
- R2 (trust establishment without a prior bilateral relationship): not met.
Mode B's single round trip rests on pre-established key material between the
upstream AS and downstream TTS (4.2.2.2); Mode A relocates the same bilateral
federation to AS configuration.
- R3 (verification without runtime dependence on the issuing side): not met.
Both modes keep an AS or TTS in the runtime path of every cross-domain hop.
- R5/R6 (integrity of the principal's delegated authority end to end): not met.
The workflow claims the downstream domain acts on are transcribed at each hop,
and 4.1.1.2 permits the transcribing AS to add, remove, or change them —
authority becomes issuer discretion at every boundary, and the audit trail
attests what each service chose to preserve rather than what the principal
delegated.
- R8 (composable cross-domain audit): partially met. The immutable txn
identifier and the accumulating req_wl trail are a real contribution here,
bounded by the transcription discretion above.
The same exercise is worth running on the other proposals in flight — Karthik's
mapping draft is the natural home for it, and I can contribute the R-by-R rows
for any proposal whose authors want them.
Morgan
On Monday, July 20th, 2026 at 8:34 AM, Liuchunchi\(Peter\)
<[email protected]> wrote:
> In the sessions, during the item “Offline workload access for user-owned
> resources without refresh tokens”, I mentioned there’s a cross-domain
> transaction token proposal. Sending the relevant draft to the list:
>
> https://datatracker.ietf.org/doc/draft-liu-oauth-cross-domain-txn-token/
>
> The draft introduces two patterns to solve cross-domain transaction tokens:
>
> • Mode A (Txn-Token I -> JAG -> Access Token -> Txn-Token II): Combines
> standard Identity Chaining with standard Transaction Tokens to pass
> workflow-related claims via JAGs and access tokens.
>
> • Mode B (Txn-Token I -> JAG -> Txn-Token II): An optimized flow allowing a
> downstream TTS to directly accept a JAG, reducing cross-domain round-trips
> for access tokens.
>
> OAuth working group is busy working on the use cases, so no solutions will be
> discussed this ietf, but this might be a relevant proposal to begin with.
> CC-ing them as well.
>
> Best,
>
> Peter
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
