Alignment with Related Protocols

[hughesthe1st]

Cross-check for compatibility with A2A, MCP, NANDA, OAuth 2.1 BCP, GNAP, and other agent-interaction specs.

[sheffler]

Beginning a comparison to other docs. Overall, the NLIP enterprise-ready checklist is a very strong document.

Comparison to MCP (https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices)

Session Hijacking

Our document covers session hijacking too w.r.t. an HTTP transport. However, our protocol specification also includes a "conversation" token in-band (in the NLIP submessages) which is our session token (as I understand it from the implementations in nlip_sdk and nlip_client). Without specifying which submessages are not to be shared with the Agent LLM our conversation token is a vector for mis-use, I believe.

(As am implementor, I may be misunderstanding the conversation id, but I think it is our session mechanism.)
Recommendation: align with industry standard HTTP, Oauth, Session handling techniques.

Mutual TLS

MCP does not appear to address Mutual-TLS. It simply suggests HTTPS. NLIP reference architecture figure suggests/requires Mutual-TLS. Suggest NLIP doc says Mutual-TLS "when appropriate".

Comparison to A2A (https://a2a-protocol.org/latest/specification/#4-authentication-and-authorization)

Reproducing A2A Sect 10.2, which has a convenient summary of main points.

10.2. Security Considerations Summary¶
Security is a paramount concern in A2A. Key considerations include:

• Transport Security: Always use HTTPS with strong TLS configurations in production environments.
• Authentication:
  • Handled via standard HTTP mechanisms (e.g., Authorization header with Bearer tokens, API keys).
  • Requirements are declared in the AgentCard.
  • Credentials MUST be obtained out-of-band by the client.
  • A2A Servers MUST authenticate every request.
• Authorization:
  • A server-side responsibility based on the authenticated identity.
  • Implement the principle of least privilege.
  • Can be granular, based on skills, actions, or data.
• Push Notification Security:
  • Webhook URL validation (by the A2A Server sending notifications) is crucial to prevent SSRF.
  • Authentication of the A2A Server to the client's webhook is essential.
  • Authentication of the notification by the client's webhook receiver (verifying it came from the legitimate A2A Server and is relevant) is critical.
  • See the Streaming & Asynchronous Operations guide for detailed push notification security.
• Input Validation: Servers MUST rigorously validate all RPC parameters and the content/structure of data in Message and Artifact parts to prevent injection attacks or processing errors.
• Resource Management: Implement rate limiting, concurrency controls, and resource limits to protect agents from abuse or overload.
• Data Privacy: Adhere to all applicable privacy regulations for data exchanged in Message and Artifact parts. Minimize sensitive data transfer.

Mutual TLS

A2A recognizes Mutual TLS as a potential security scheme that can be specified in the Agent Card. With A2A, Mutual TLS is a supported option, but not a requirement.

Push NotificationS

A2A makes a provision for a Client (server) to receive Push notifications over an HTTP callback. The spec defines unique tokens and security schemes for this backchannel. NLIP does not have such a mechanism and does not need these mechanisms.

[sheffler]

@hughesthe1st performed some initial reviews. Will update the above comment as it proceeds.

[sheffler]

(I can't open a PR against a .pdf file so I am putting this comment in here. )
@hughesthe1st @ted-ross @dineshverma @aiyagari

Make Authentication, Authorization, Sessions and Conversations the responsibility of the encapsulating protocol.

These have to do with the establishment and authorization of a channel.

As part of the review of our security document, other protocols and our base spec, I recommend removing the handling of a "token" and authentication, sessions and conversations from the NLIP payload specification. Align with customary use of Headers in HTTP and appropriate mechanisms in AMQP.

Our security document describes the best handling of Authentication and Session cookies, while our NLIP payload specification also includes these concepts. They contradict one another.

Recommended changes to ecma_draft/tc56-2025-017.pdf

p. 4 - remove "token" definition from table
p. 4:
  6 'Mandatory Exchanges"
  6.2 Requests containing token field 
  6.5 Requests for authentication 


  7.2 Authentication

[leave as-is]
The base transfer protocol must implement or enable authentication among the client and server. While the
exchange of NLIP messages can happen without authentication between the client and server, the server or
the client can ask for authentication. The mechanism for authentication may happen using any existing
authentication scheme supported by the base transfer protocol.

[added text]
An example of an Authentication protocol is the use of OAuth over HTTP.  If using NLIP over HTTP,
with Oauth, the Authorization header will carry a Bearer token if required.  If the endpoint requires
authorization and it is not present, the server will respond with a "401: Authorization Required" response.

[added text]
Another example of an Authentication protocol is the use of SASL with Oauth over AMQP.  In such a scenario,
SASL can be used to request the OAuth token that the client should provide.

[added section]
  7.3 Sessions and Conversations

  The base protocol should provide a means to establish a session between a client and a server exchanging NLIP.
  In addition, provisions of the base protocol should be used to track individual conversations (a series
  of exchanges on the same topic) within a session.

  For instance, if the base protocol is HTTP, then the Cookie mechnanism can be used
  for a server to provide a "Session" cookie that the client will include in any future requests.  Similarly, if the
  server can manage multiple NLIP conversations within a session, a "Conversation-ID" cookie should be
  provided.  The specific names of the cookies are not specified in this document.

  If the base protocol is AMQP, then it is appropriate to manage the session as an AMQP session.  NLIP
  conversations occuring within the session are mapped to the "correlation-id" field of an AMQP message.
 

[aiyagari]

manage multiple NLIP conversations within a session, a "Conversation-ID" cookie should be
provided. The specific names of the cookies are not specified in this document.

If the cookie name is defined in the binding document, then it should be left to the binding document. I would suggest "a cookie should be provided as specified in the HTTP binding specification" - that way the specific format of the cookie can be defined there.

For AMQP, I would suggest the wording: "Session and conversation semantics are natively handled by AMQP and mappings are defined in the AMQP binding specification."