From: Mohamad Khalil Yossif <mohamad@yuthent.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_14B16026-20C4-49B1-B00D-A851DF377731"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Message-Id: <3E646F58-52F1-4FA7-B875-47528D43D1AD@yuthent.com>
Date: Wed, 5 Aug 2026 09:43:45 +0300
To: oauth@ietf.org
Message-ID-Hash: K22TUQWUQZ6Y4KB4AN4ZVPO2QZ7R7LQI
CC: me@karlmcguinness.com
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?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/_o3g0mSIuDJNrXslPeuOxPy0My4>


--Apple-Mail=_14B16026-20C4-49B1-B00D-A851DF377731
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


> Karl,
> 
> I have been meaning to write to you since George Fletcher pointed me
> at Mission-Bound Authorization on this list on 22 July. I said then
> that I would treat it as primary related work in a revision of my own
> draft and have not yet done so, which is my delay, not an oversight.
> ICA is a better occasion than the one I was waiting for.
> 
> The framing that interests me is your first sentence about the
> absence: the user is not present at the hop, and redirecting to the
> identity provider is not an option. That is the same observation I
> started from and we have gone opposite directions with it.
> 
> ICA answers it by having each boundary mint fresh, so no credential
> travels and no component holds standing authority. I answer it by
> requiring evidence produced at the moment of the action by a key the
> invoking runtime cannot reach - which means my construction simply
> fails in the case ICA is built for. If the user has gone offline
> there is no proof to produce, and a profile that says "then refuse"
> is not a solution to a continuation problem.
> 
> So these are complementary rather than competing, and I think the
> seam between them is worth naming.
> 
> Your minting boundary establishes that this identity is a legitimate
> continuation of that one. It does not establish, and does not claim
> to, that the human agreed to what happens at the far end. Nor should
> it - the human is absent by construction. But an agent continuing
> work across four hops with correctly minted assertions at each is
> still an agent whose original mandate said one thing and whose fourth
> hop does another, and nothing in the chain refuses that.
> 
> Two questions, both narrow and both about what ICA deliberately does
> not carry rather than what it does.
> 
> Does the minting boundary carry anything about what the original
> authorization permitted - a scope, a constraint set, an action class -
> or is the assertion purely about identity continuity? Your phrasing
> "re-subjecting across a boundary as a mint rather than an attenuation"
> reads as deliberate on this point, and I would rather understand the
> choice than infer it.
> 
> And where a chain of correctly minted assertions arrives at a
> consequential action, is the receiving service expected to have any
> independent evidence of authorization, or is the chain itself the
> authorization? I am not suggesting ICA should answer that. I am
> asking whether you see it as in scope.
> 
> I ask because the second one is the layer I work on, and if ICA's
> answer is "out of scope, and a separate artifact should carry it",
> then the two compose cleanly and I would rather cite that than assume
> it. If your answer is that the chain is sufficient, I would want to
> understand why, because it is the case my draft exists to refuse.
> 
>   draft-yossif-psea, execution-time authorization evidence
>   https://datatracker.ietf.org/doc/draft-yossif-psea/
> 
>   draft-yossif-agent-mandate-problem, the constraint set a human
>   signs before the agent acts - the T0 half of the same problem
>   https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
> 
> The second is a problem statement with no mechanism proposed. If ICA
> does carry constraint information across the mint, it may already
> answer part of what that draft only states.
> 
> Mohamad Khalil-Yossif


--Apple-Mail=_14B16026-20C4-49B1-B00D-A851DF377731
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dus-ascii"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div dir=3D"auto" style=3D"overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div =
class=3D"Apple-Mail-URLShareUserContentTopClass"><br></div><div =
class=3D"Apple-Mail-URLShareWrapperClass" style=3D"position: relative =
!important;"><blockquote type=3D"cite" style=3D"border-left-style: none; =
color: inherit; padding: inherit; margin: inherit;">

Karl,<br><br>I have been meaning to write to you since George Fletcher =
pointed me<br>at Mission-Bound Authorization on this list on 22 July. I =
said then<br>that I would treat it as primary related work in a revision =
of my own<br>draft and have not yet done so, which is my delay, not an =
oversight.<br>ICA is a better occasion than the one I was waiting =
for.<br><br>The framing that interests me is your first sentence about =
the<br>absence: the user is not present at the hop, and redirecting to =
the<br>identity provider is not an option. That is the same observation =
I<br>started from and we have gone opposite directions with =
it.<br><br>ICA answers it by having each boundary mint fresh, so no =
credential<br>travels and no component holds standing authority. I =
answer it by<br>requiring evidence produced at the moment of the action =
by a key the<br>invoking runtime cannot reach - which means my =
construction simply<br>fails in the case ICA is built for. If the user =
has gone offline<br>there is no proof to produce, and a profile that =
says "then refuse"<br>is not a solution to a continuation =
problem.<br><br>So these are complementary rather than competing, and I =
think the<br>seam between them is worth naming.<br><br>Your minting =
boundary establishes that this identity is a legitimate<br>continuation =
of that one. It does not establish, and does not claim<br>to, that the =
human agreed to what happens at the far end. Nor should<br>it - the =
human is absent by construction. But an agent continuing<br>work across =
four hops with correctly minted assertions at each is<br>still an agent =
whose original mandate said one thing and whose fourth<br>hop does =
another, and nothing in the chain refuses that.<br><br>Two questions, =
both narrow and both about what ICA deliberately does<br>not carry =
rather than what it does.<br><br>Does the minting boundary carry =
anything about what the original<br>authorization permitted - a scope, a =
constraint set, an action class -<br>or is the assertion purely about =
identity continuity? Your phrasing<br>"re-subjecting across a boundary =
as a mint rather than an attenuation"<br>reads as deliberate on this =
point, and I would rather understand the<br>choice than infer =
it.<br><br>And where a chain of correctly minted assertions arrives at =
a<br>consequential action, is the receiving service expected to have =
any<br>independent evidence of authorization, or is the chain itself =
the<br>authorization? I am not suggesting ICA should answer that. I =
am<br>asking whether you see it as in scope.<br><br>I ask because the =
second one is the layer I work on, and if ICA's<br>answer is "out of =
scope, and a separate artifact should carry it",<br>then the two compose =
cleanly and I would rather cite that than assume<br>it. If your answer =
is that the chain is sufficient, I would want to<br>understand why, =
because it is the case my draft exists to refuse.<br><br><span =
class=3D"Apple-converted-space">&nbsp;</span> draft-yossif-psea, =
execution-time authorization evidence<br><span =
class=3D"Apple-converted-space">&nbsp;</span> =
https://datatracker.ietf.org/doc/draft-yossif-psea/<br><br><span =
class=3D"Apple-converted-space">&nbsp;</span> =
draft-yossif-agent-mandate-problem, the constraint set a human<br><span =
class=3D"Apple-converted-space">&nbsp;</span> signs before the agent =
acts - the T0 half of the same problem<br><span =
class=3D"Apple-converted-space">&nbsp;</span> =
https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/<br><b=
r>The second is a problem statement with no mechanism proposed. If =
ICA<br>does carry constraint information across the mint, it may =
already<br>answer part of what that draft only states.<br><br>Mohamad =
Khalil-Yossif

</blockquote></div><br><br>
<br></div></body></html>=

--Apple-Mail=_14B16026-20C4-49B1-B00D-A851DF377731--