Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A5F5A1243DE72 for ; Wed, 5 Aug 2026 10:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785951024; bh=hvNV7GBaA9y8qB841NDPUgAryqZVFKMkVoPVfBzkrcY=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Dq25e3GShRPyHs2VAqTd0ovLAKEWKfTqo5EBHKlcF4thaV9GD+IXNAhHah6DIAuDK mdOKpUgYpB8Q6q21SzRs1aMZwaMPAmC/Ygn16UXxWSMDpy8rNfqaDev6Z3WLFu73XN UU9M8D5ohFPJxpp0BWu6y39Bt3e5DAp8Gj8FK5cc= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=karlmcguinness.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqAZjwDvmhK2 for ; Wed, 5 Aug 2026 10:30:24 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EF0D41243DE6B for ; Wed, 5 Aug 2026 10:30:23 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4953e04ef16so12297975e9.2 for ; Wed, 05 Aug 2026 10:30:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785951023; cv=none; d=google.com; s=arc-20260327; b=KiGZ1uFv+jxth9lNWYRecYVY+xLP866UGE+OiQt0aG/h92sU659R9Oqnd276gVnscg ObFQttY47Av3cByxDV00zQenMq5j9IDE9s2sF6gqN1XfN0H0D42LS7oKCYLCr9LHVlQI ACHWT2PapxNwQmEH5S+7Gj7mVsqNvbVodytkbIESnA//Rc8/vKmwLs+AY5Hd/MF2/gpT krLirI5T9B2Mo6TtMhbFvtOWpx8mAVnIUqONtroU+plvT31dNDS6HBpsB8/z1g5YRzUe ZlspinIhVMsVH3WFeqbsY0OzLatGPC+E9eIZQ3ji4osytvLQ2M3IaqSe+4e7/IA+VFZ+ eSyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=A3EvbKiPqhGrwlr5E6cj9EL9VDAMCxcV3ZnL/JZGWoM=; fh=k4gO8uJPLEl6D+T1nqyexptLzPWcziatZ35ElX0FcYM=; b=CLDepqYuxAgySqDmS3mthLIaANz6ogIsy0pANIi7UMK2h6fJYXRW0cwzDrWrXJ0/+c zqO3iDmAr0G1/C+8nSsmZlerAtggvZFUGDiIf7uPY+VsRAnG34PW98HrPWLmpvcGteOq sMzaMY8WpsOc9NFAUYeVaz0RqZ9R2T6WXtSXD+Rdos4L285YuL2EbKW4pCbMK5LturDl 4Ysc8DHBrfaNoVlrRuT/dueUl4E8NLQYLHyggb9Y8NPonUw8Fb1mHzOPrnFcY3FyDTpX Tt3VENZBjOwXjuG5h7f6nARADjZX9WZxGrfV6aVC4kaVsKO/bNnKaEunUL0R6BCjxkvq BJ1g==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karlmcguinness.com; s=google; t=1785951023; x=1786555823; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=A3EvbKiPqhGrwlr5E6cj9EL9VDAMCxcV3ZnL/JZGWoM=; b=UUsZBZujiJ+GCbuZ/Zg+n3ci6fu9eYA8TLjW89Pbep+v/sDskCYy4IXpAG1ARq2kOa T8sPYQ0AIWKQTjrcFtp625BHMROE2qJZEXIqbSs3pKUz73JneWwwfYoHLiQPg7N2p5Bd FPioJhsYwxK3QtmoSYpYfxgIvcux+XpLhf2cSgzT803sf+PFWAMsCbAzNGF+nm9MkF9q dxrMs0Rfjfhqgt1Uv9FOYlhsf5yjrA1MPBNtGVHh/604XkZ2A2kEkkoV96/H3Gvp8AgI yPFNbLuJzCsmADtPqLpf+StHESWdA7w53+moZZvfZTo/ge2KwLcqGKdj+52VqancYbuc ymJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785951023; x=1786555823; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=A3EvbKiPqhGrwlr5E6cj9EL9VDAMCxcV3ZnL/JZGWoM=; b=hfcW13/IB5wYnWqoQvzYec+N9Zlj+yqPLUYWC+8atKtumx3tb8X69N5AIdwBJUPvOu UuLQYS2EzyIFctuZXy44vROkSrdPU+j5ypw+FQSJjSY6Cv3K4UvHXWDvmp/2dODx7zPf hTmLiZhOEsm3d6KHBnKUtDetcxNcr+2mE7Sn3dPiCBlrH05gjsR4HKGacnqs5D6MpgbY yIJxQqDzb1Tbd4hi14wHWSoB8mCdDqegrr8XW3vdl46F0rMaWHISqN++Pv2e0OjacAFA dm6Bt86FkjhvMKyZkUupmzbnVtWyFrOOH0fCJo36PYy/jSca+e5F0asCswxCi6LTvqFy bqig== X-Gm-Message-State: AOJu0Yx2jBtpOV3CbccqFy1zrH0PkPBrEvHr5TD11/j469VK+uNqT/2/ B6vqdAxDK8m3V+HgxXHoy369st4SekwtPpweHvZ+QdnFoLpSj5EMPzwUCh+J3FMANaapu4pq66v XsT28988EjN9q/oQp9+MVGH0ZsX10YW5SEVnRIm6J2nBeQYSHklt+K17+lA== X-Gm-Gg: AR+sD13+UPvMLummNndTk22KGsNd4p2SYVz9tsXM5LOtZ5KY0nFxk69b1+gk6FRynzF 6eDpuXWJxYbrbbhSEe36DgzPDWeDkbwHssW7UResvefNQfY6nDB71nuWCtJFUM+h26DyM05MNsI k+wc82S6PBe14/YKeWF+4oNsY/qP2KDpJ+xHoZMfQUx+QV1GPg8TW+PIxK9NMs1snOEkHQBys42 uYlLnitfPsf9n2H0tNPUVed56eY7sDz9Qwgxka5mSraaat1s2JQ4Rf447REy/lTHclyDzVe5jTO zrHG28//Bhg6l7iDmF2aCfOsi1B69+o2nNelBTGgYpaETUyx+ukfXI+eVadTX6krih7TBzxylnZ gy+HsATMNJgmOMM5v6tgxi5uk24nIVb/GqsQqECtd+UH94g5A9G1V8Fed0ixxrHeENnJuiVzmBB Cg27aq2a47cg== X-Received: by 2002:a05:600c:c490:b0:493:c337:db0e with SMTP id 5b1f17b1804b1-4994e7ece20mr111597745e9.18.1785951022590; Wed, 05 Aug 2026 10:30:22 -0700 (PDT) MIME-Version: 1.0 References: <3E646F58-52F1-4FA7-B875-47528D43D1AD@yuthent.com> In-Reply-To: <3E646F58-52F1-4FA7-B875-47528D43D1AD@yuthent.com> From: Karl McGuinness Date: Wed, 5 Aug 2026 10:30:10 -0700 X-Gm-Features: AUfX_mx-KZb46vPypOsrA6dASw7pMaD6wUnZz3mDY-yCAcHCCuYJIRj8j4xNdsQ Message-ID: To: Mohamad Khalil Yossif Content-Type: multipart/alternative; boundary="00000000000049bd6b0658502028" Message-ID-Hash: SVVNSWLLYK46VMEJWP6MTVGKSVKIJ5IB X-Message-ID-Hash: SVVNSWLLYK46VMEJWP6MTVGKSVKIJ5IB X-MailFrom: me@karlmcguinness.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: oauth@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_New_I-D=3A_Identity_Continuation_Assertion_fo?= =?utf-8?q?r_OAuth_2=2E0_Token_Exchange_=28request_for_review=29?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000049bd6b0658502028 Content-Type: text/plain; charset="UTF-8" Mohamad, Thank you for this, and no rush on the revision. I'm glad George connected the threads. Your two questions draw the boundary more sharply than my draft currently does. The short version first: identity continuity is in scope for ICA. Authorization continuity, carrying the decision itself forward, is out of scope by design. Execution-time evidence was never in ICA's frame at all. Each belongs in its own artifact. I'll make that boundary explicit in the next revision so there is something stable to cite. On your first question, the answer depends on which artifact you mean. The Identity Continuation Assertion, the artifact a service presents at the mint, carries no scopes, action classes, or constraint sets. The ID-JAGs on either side of it can carry scopes and authorization_details, both the grant that starts a chain and the one each mint produces, but those are the identity provider's fresh per-hop decisions, not authorization state carried forward from the upstream domain. That's the choice behind "a mint rather than an attenuation": there is nothing in the assertion to attenuate, so every hop is a fresh mint. Section 4 of the draft says it directly. The mint is still bounded by the grant the chain roots in, the identity provider's policy on who may continue, and revocation. On your second question, I keep coming back to SSO, because it is the core model behind ID-JAG and Cross App Access (XAA). Federation has always made this split: the assertion carries who the user is into a new domain, sometimes with attributes that inform the local decision, and the receiving domain decides what the user may do there. The assertion is an input to that decision, not the decision itself. ICA extends that split to the hops a redirect cannot reach. Chains literally root in a grant or session the identity provider already holds, the OIDC or SAML session itself among them, and each mint continues the identity, with permissions decided fresh at every hop. The identity provider is still not a bystander: it gates each mint and shapes what may be requested of the next domain, while the receiving authorization server makes the final decision for its own domain. Two authorities, each deciding what is theirs to decide. The comparison breaks in one important place, which is where working-group discussion is most valuable. Classic SSO made its split with the human present at each new domain, consenting at a screen. ICA extends it to the hops where the human is absent by construction, so what the split leaves to local policy carries more weight than it ever did in browser SSO. The draft answers half of it: the root-chain envelope, whose every dimension is an establishment-time ceiling that later policy may narrow but never broaden. The other half is open item 9 in Appendix C, whether the envelope should expose a testable representation of the authorization ceiling, and whether that representation is scopes, an authorization detail, or something policy-bound. If you read the open items, that one is closest to your territory. Your four-hop agent is a good test of what that leaves open. The identity provider polices who may continue the chain and for how long, and it can end the chain at the next mint. What nothing in the chain checks is whether the fourth hop still matches what the human agreed to at the start. The chain carries who is acting and what each domain may be asked. It does not carry what the human approved to be done, which I think is the seam you were pointing at. Your agent-mandate-problem draft names that missing layer at T0: the constraint set a human signs before the agent acts. To your closing question: ICA does not carry constraint information across the mint, and does not already answer what your draft states. That layer needs its own artifact. Mission-Bound Authorization is one approach: it governs the approved work itself, carrying the constraints, approval evidence, and lifecycle independently of the identity chain. PSEA sits at a third point. Where a mandate captures what was approved at T0, PSEA produces evidence that a particular execution was authorized at the moment it occurred. And you said it yourself with the offline user: PSEA covers the hop where the human is present to prove it, ICA the hop where they are not. Correct me if I have any of that wrong. So I don't see competing approaches. I see three layers that compose: - identity continuity (ICA, issuing ID-JAGs): who is acting, and how that identity legitimately continues across domains, - authorization continuity (your mandate layer, with draft-mcguinness-oauth-mission as one proposed mechanism): what work remains authorized, under which constraints, on whose approval, and - execution-time evidence (PSEA): proof a specific action was authorized when it happened. Each answers a question the others don't, and one artifact trying to carry all three would do each job worse. -Karl --00000000000049bd6b0658502028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Moham= ad,

Thank you for t= his, and no rush on the revision. I'm glad George connected the threads= . Your two questions draw the boundary more sharply than my draft currently= does.

The short ve= rsion first: identity continuity is in scope for ICA. Authorization continu= ity, carrying the decision itself forward, is out of scope by design. Execu= tion-time evidence was never in ICA's frame at all. Each belongs in its= own artifact. I'll make that boundary explicit in the next revision so= there is something stable to cite.

On your first question, the answer depends on which artifa= ct you mean. The Identity Continuation Assertion, the artifact a service pr= esents at the mint, carries no scopes, action classes, or constraint sets. = The ID-JAGs on either side of it can carry scopes and authorization_details= , both the grant that starts a chain and the one each mint produces, but th= ose are the identity provider's fresh per-hop decisions, not authorizat= ion state carried forward from the upstream domain. That's the choice b= ehind "a mint rather than an attenuation": there is nothing in th= e assertion to attenuate, so every hop is a fresh mint. Section 4 of the dr= aft says it directly. The mint is still bounded by the grant the chain root= s in, the identity provider's policy on who may continue, and revocatio= n.

On your second q= uestion, I keep coming back to SSO, because it is the core model behind ID-= JAG and Cross App Access (XAA). Federation has always made this split: the = assertion carries who the user is into a new domain, sometimes with attribu= tes that inform the local decision, and the receiving domain decides what t= he user may do there. The assertion is an input to that decision, not the d= ecision itself. ICA extends that split to the hops a redirect cannot reach.= Chains literally root in a grant or session the identity provider already = holds, the OIDC or SAML session itself among them, and each mint continues = the identity, with permissions decided fresh at every hop. The identity pro= vider is still not a bystander: it gates each mint and shapes what may be r= equested of the next domain, while the receiving authorization server makes= the final decision for its own domain. Two authorities, each deciding what= is theirs to decide.

The comparison breaks in one important place, which is where working-gro= up discussion is most valuable. Classic SSO made its split with the human p= resent at each new domain, consenting at a screen. ICA extends it to the ho= ps where the human is absent by construction, so what the split leaves to l= ocal policy carries more weight than it ever did in browser SSO. The draft = answers half of it: the root-chain envelope, whose every dimension is an es= tablishment-time ceiling that later policy may narrow but never broaden. Th= e other half is open item 9 in Appendix C, whether the envelope should expo= se a testable representation of the authorization ceiling, and whether that= representation is scopes, an authorization detail, or something policy-bou= nd. If you read the open items, that one is closest to your territory.

<= p style=3D"margin:15px 0px;color:rgb(0,0,0);font-family:Helvetica,arial,san= s-serif;font-size:14px;text-decoration-style:solid">Your four-hop agent is = a good test of what that leaves open. The identity provider polices who may= continue the chain and for how long, and it can end the chain at the next = mint. What nothing in the chain checks is whether the fourth hop still matc= hes what the human agreed to at the start. The chain carries who is acting = and what each domain may be asked. It does not carry what the human approve= d to be done, which I think is the seam you were pointing at.

Your agent-mandate-problem dra= ft names that missing layer at T0: the constraint set a human signs before = the agent acts. To your closing question: ICA does not carry constraint inf= ormation across the mint, and does not already answer what your draft state= s. That layer needs its own artifact.=C2=A0Mission-Bound Authorization=C2=A0is one approach:= it governs the approved work itself, carrying the constraints, approval ev= idence, and lifecycle independently of the identity chain.

PSEA sits at a third point. Where a= mandate captures what was approved at T0, PSEA produces evidence that a pa= rticular execution was authorized at the moment it occurred. And you said i= t yourself with the offline user: PSEA covers the hop where the human is pr= esent to prove it, ICA the hop where they are not. Correct me if I have any= of that wrong.

So = I don't see competing approaches. I see three layers that compose:

<= ul style=3D"margin:15px 0px;padding-left:30px;color:rgb(0,0,0);font-family:= Helvetica,arial,sans-serif;font-size:14px;text-decoration-style:solid">
  • identity continuity (ICA, issuing ID-JAGs): who is act= ing, and how that identity legitimately continues across domains,
  • authorization continuity (your mandate layer, with=C2=A0draft-mcguinness-oauth-mission=C2=A0as one proposed mechanism): what = work remains authorized, under which constraints, on whose approval, and
  • execution-time evidence (PSEA): proof a specific= action was authorized when it happened.

    • Each answers a question the others don't, a= nd one artifact trying to carry all three would do each job worse.

    -Karl

    --00000000000049bd6b0658502028--