[dispatch] Re: Request for DISPATCH consideration: draft-sogomonian-aiip-aiid-00`

[Aram Sogomonian <[e-mail]>]

the forbid is on agent use of `http:`/`https:` as the Resolve/Invoke application path(consequential action). Humans still use HTTPS for HQ. TLS/QUIC underlay for AIIP is fine. Gate/registry/policy enforce — not DPI of the Webb 

> On Sep 22, 2026, at 00:08, Aram Sogomonian <[e-mail]> wrote:
> 
> 
> Jim,
> 
> Thanks for the comments (and for taking this to the list).
> 
> On agents and HTTP/HTTPS: the intent is a hard plane split, not a ban on intelligence or on TLS. HTTPS remains the human control plane (HQ, browsers, operators). Consequential agent action is meant to go Resolve → Invoke → signed Receipt on AIIP, so grant, freeze, and accountability have one choke point an owner can operate. TLS/QUIC as underlay for AIIP messages is fine. Enforcement is policy plus gate (fail closed when not authorized), not deep inspection of the open Web. I’m happy to sharpen that wording in the next revision so it doesn’t read as “forbid HTTP.”
> 
> On interest outside AIIF: fair point. This is still early individual Experimental work. I’m seeking implementer and operator interest (including venues such as HotRFC lightning talks) rather than asking Dispatch to manufacture that interest. Agreed it is too early for a meeting slot until that picture is clearer.
> 
> On specificity in draft-sogomonian-aiip-core (grants): accepted. “Signed fields + Base64” is not a wire format. The next revision should pick a normative profile (e.g. JWS [RFC7515]) and spell out encapsulation and delimiters. Thanks for the concrete pointer to Section 9.
> 
> On prototype: there is a lab implementation (public tips / doors, Resolve, Invoke, and signed receipts), not a multi-organization deployment. Happy to point people at what exists if useful for discussion.
> 
> On packaging and a Dispatch slot: I agree the fundamental questions above come first. List discussion plus clearer drafts and external interest before any meeting ask. Guidance welcome on whether to keep AIID+AIIP under one umbrella document or split further once the interest/spec questions settle.
> 
> Thanks again,
> Aram Sogomonian
> [e-mail]
> https://datatracker.ietf.org/doc/draft-sogomonian-aiip-aiid/
> 
> 
> 
> 
>> On Sep 21, 2026, at 22:27, Jim Fenton <[e-mail]> wrote:
>> 
>> Comments inline.
>> 
>>>> On 20 Sep 2026, at 14:56, Aram Sogomonian wrote:
>>> 
>>> Dear DISPATCH participants,
>>> 
>>> I am requesting DISPATCH consideration for a new individual Experimental
>>> Internet-Draft:
>>> 
>>> draft-sogomonian-aiip-aiid-00
>>> https://datatracker.ietf.org/doc/draft-sogomonian-aiip-aiid/
>>> 
>>> Title: AIIP/AIID: No-Surprise Autonomous Action, Identity, Access Plane,
>>> Receipt, and Revocation
>>> 
>>> Summary: durable principal identity (AIID) co-deployed with an agents-only
>>> access plane (AIIP). The primary rule is no surprise: autonomous systems
>>> MUST NOT act outside their authorized task and grant. Consequential action
>>> uses Resolve, Invoke, and a signed Receipt on AIIP. Controls include
>>> Monitor set-only freeze (safe_mode), HQ-only set-active / revoke, and
>>> network-wide freeze. HTTPS remains the human control plane; agents MUST NOT
>>> use HTTP/HTTPS as their consequential action path (underlay TLS/QUIC for
>>> AIIP messages is out of scope of that ban).
>> 
>> I didn’t understand much of that summary, which could be because I’m not up on AI technology but also perhaps not. The statement that agents MUST NOT use HTTP/HTTPS jumps out at me; what is the reason they can’t share the same mechanisms as humans and how would this be enforced? Restricting agents to a specific subset of protocols doesn’t seem like a very effective way of constraining their behavior, if that is the intent.
>> 
>>> This is an individual submission prepared under AIIF (Artificial Intelligence
>>> Internet Foundation). It does not claim Working Group adoption or RFC status.
>> 
>> As we have asked in the past, are there others outside AIIF that are interested in developing and implementing this architecture and protocol? If you have not engaged with some, it is probably too early to dispatch.
>> 
>>> Companion individual drafts already on the Datatracker include:
>>> - draft-sogomonian-aiid-namespace
>>> - draft-sogomonian-aiip-architecture
>>> - draft-sogomonian-aiip-core
>>> - draft-sogomonian-aiip-native-access-architecture
>>> - draft-morrow-sogomonian-exec-outcome-attest (co-authored)
>> 
>> I read quickly through this draft and -aiip-core, which I think is intended to be the protocol document. The core document didn’t seem to be nearly specific enough to be a protocol specification. To pick a random example, in Section 9 (Grants), “Full grant object = signed fields + signature (Base64).” doesn’t say anything about how this is encapsulated. Are there delimeters, or is this a JWS [RFC7515] or something?
>> 
>> Have you or anyone done a prototype implementation of this?
>> 
>>> Questions for DISPATCH:
>>> 
>>> 1) Is there an existing WG whose charter covers agent principal identity
>>>  plus access-plane controls (freeze / receipt / grant), or would DISPATCH
>>>  recommend AD-sponsored individual progression, a BoF, a dedicated list,
>>>  or deferral?
>>> 
>>> 2) Preference on packaging: keep AIID and AIIP as companions with this wrap
>>>  as the architectural umbrella, or a different split?
>> 
>> There are more fundamental questions that need to be resolved before considering the packaging.
>> 
>>> 3) Is a DISPATCH meeting slot appropriate after list discussion, or is list
>>>  feedback enough for now?
>> 
>> List discussion alone is likely to be insufficient.
>> 
>> -Jim (as participant)