[saag] ZTNP / ZTIP – attestation-gated authorization & intent-bound delegation (seeking venue guidance)

--===============5886106332525245280==
Content-Type: multipart/alternative; boundary="000000000000667e92065078f0c4"

--000000000000667e92065078f0c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I=E2=80=99ve recently submitted two individual Internet-Drafts that explore=
 gaps
we=E2=80=99re encountering as systems become more agent-driven and involve
multi-hop delegation:

ZTNP (Zero-Trust Negotiation Protocol)
https://datatracker.ietf.org/doc/draft-miller-ztnp/

ZTIP (Zero-Trust Intent Protocol)
https://datatracker.ietf.org/doc/draft-miller-ztip/

At a high level:

   - *ZTNP* looks at how to bind attestation (or posture) to authorization
   at session establishment, including channel binding and local policy
   evaluation by the relying party.
   - *ZTIP* explores how to bind authorization to structured user intent
   across delegation chains, with explicit scope monotonicity and end-to-en=
d
   verifiability.

The drafts explore a potential gap between:

   - attestation (e.g., RATS-style evidence/results), and
   - authorization mechanisms (OAuth / GNAP)

This is particularly true in scenarios where actions are delegated across
multiple agents and are susceptible to prompt injection or confused deputy
patterns.

These drafts are intended as early contributions. I=E2=80=99m interested in
critical feedback, especially on:

   - whether the problem framing resonates
   - how this relates to existing work in OAuth, GNAP, and RATS
   - and whether there is an appropriate venue (existing WG or otherwise)
   for further discussion

Thank you for any feedback or direction.

Best regards,
Jake Miller
[email protected]

--000000000000667e92065078f0c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><p>Hello,</p>
<p>I=E2=80=99ve recently submitted two individual Internet-Drafts that expl=
ore gaps we=E2=80=99re encountering as systems become more agent-driven and=
 involve multi-hop delegation:</p>
<p>ZTNP (Zero-Trust Negotiation Protocol)<br>
<a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://datatrac=
ker.ietf.org/doc/draft-miller-ztnp/">https://datatracker.ietf.org/doc/draft=
-miller-ztnp/<span aria-hidden=3D"true" class=3D"gmail-ms-0.5 gmail-inline-=
block gmail-align-middle gmail-leading-none"></span></a></p>
<p>ZTIP (Zero-Trust Intent Protocol)<br>
<a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://datatrac=
ker.ietf.org/doc/draft-miller-ztip/">https://datatracker.ietf.org/doc/draft=
-miller-ztip/<span aria-hidden=3D"true" class=3D"gmail-ms-0.5 gmail-inline-=
block gmail-align-middle gmail-leading-none"></span></a></p>
<p>At a high level:</p>
<ul>
<li>
<strong>ZTNP</strong> looks at how to bind attestation (or posture) to auth=
orization at session establishment, including channel binding and local pol=
icy evaluation by the relying party.
</li>
<li>
<strong>ZTIP</strong> explores how to bind authorization to structured user=
 intent across delegation chains, with explicit scope monotonicity and end-=
to-end verifiability.
</li>
</ul>
<p>The drafts explore a potential gap between:</p>
<ul>
<li>
attestation (e.g., RATS-style evidence/results), and
</li>
<li>
authorization mechanisms (OAuth / GNAP)</li>
</ul>
<p>This is particularly true in scenarios where actions are delegated acros=
s multiple agents and are susceptible to prompt injection or confused deput=
y patterns.</p>
<p>These drafts are intended as early contributions. I=E2=80=99m interested=
 in critical feedback, especially on:</p>
<ul>
<li>
whether the problem framing resonates
</li>
<li>
how this relates to existing work in OAuth, GNAP, and RATS
</li>
<li>
and whether there is an appropriate venue (existing WG or otherwise) for fu=
rther discussion
</li>
</ul>
<p>Thank you for any feedback or direction.</p>
<p>Best regards,<br>
Jake Miller<br>
<a class=3D"gmail-decorated-link gmail-cursor-pointer" rel=3D"noopener">jak=
[email protected]</a></p></div></div>

--000000000000667e92065078f0c4--


--===============5886106332525245280==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls
aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHNhYWctbGVhdmVAaWV0Zi5vcmcK

--===============5886106332525245280==--