[OAUTH-WG] Re: [agent2agent] Re: Re: Review of draft-rosenberg-oauth-aauth-00

["Lombardo, Jeff" <[e-mail]>]

The main difference is passing PII (Which is not authenticator but identifiers as per name) as credential which are sensitive static information that either 1/ cannot be changed (name, SSN, etc.) or 2/ will generate a lot of impacts if to be changed versus passing a temporary credential (Authorization Code) valid only for the agent to obtain the real access token. Access Token which by default is opaque unless JWT profiled, and even there,  privacy preserving options like SD-JWT exist.

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
( [phone]

Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

From: Leonard Rosenthol <[e-mail]>
Sent: July 25, 2025 6:12 PM
To: Lombardo, Jeff <[e-mail]>; [e-mail]
Cc: Nick Watson <[e-mail]>; Patrick White <[e-mail]>; [e-mail]; [e-mail]; Lombardo, Jeff <[e-mail]>
Subject: RE: [EXT] [OAUTH-WG] Re: [agent2agent] Re: Re: Review of draft-rosenberg-oauth-aauth-00


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

> The fact that authentication needs to be performed to the AS directly with the minimal number of intermediary is another important notion which is not respected here.
>
Why do you see that as a consideration?

Thinking about the situation where a given agent can choose to delegate some/all of its work to one or more other agents, I would think that any authentication/authorization information (regardless of technology/format) would continue to be passed along the flow.

We have to remember that unlike today’s world of “predefined routes” – in this “agentic world”, we (humans, sysops, devs, etc.) don’t have control over the way in which data will flow….

Leonard

From: Lombardo, Jeff <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 25, 2025 at 8:18 AM
To: Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Nick Watson <[e-mail]<mailto:[e-mail]>>, Patrick White <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Lombardo, Jeff <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OAUTH-WG] Re: [agent2agent] Re: Re: Review of draft-rosenberg-oauth-aauth-00

EXTERNAL: Use caution when clicking on links or opening attachments.


The draft, unfortunately, revolves around the fact that this data payload passed to the agent for the AS is different pieces of PII (a static, non secret cause leaked so often, set of identifiers).

That is what does not smell good.

The fact that authentication needs to be performed to the AS directly with the minimal number of intermediary is another important notion which is not respected here.

Jean-François “Jeff” Lombardo | Amazon Web Services


From: Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>
Sent: July 25, 2025 8:25 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Nick Watson <[e-mail]<mailto:[e-mail]>>; Lombardo, Jeff <[e-mail]<mailto:[e-mail]>>; Patrick White <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [EXT] [OAUTH-WG] Re: [agent2agent] Re: Re: Review of draft-rosenberg-oauth-aauth-00


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

You’ve have to forgive me, Dick (and others), but I am coming to this discussion not as an OAuth person – so I had to look up all the acronyms that are freely flowing.  But I think I am caught up – at least for now 😉.

> Having an agent obtain information about the user to authenticate to the AS smells like a bad idea
>
I would actually state it more as the “user provides information to the agent”.  For example, if the agent’s protocol declaration defines that it requires some form of information from a user – be it auth token, VC, etc. – how is that any different from how REST APIs work today, where API declarations frequently (almost always!) include such info??   That information passes across the protocol (e.g., HTTP today), is picked up by some system on the other side, checked for authorization and/or entitlement, and if valid “allowed to pass on” to the actual process.  I see agents working the same way.

Leonard


From: Dick Hardt <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 24, 2025 at 10:10 AM
To: Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>
Cc: Nick Watson <[e-mail]<mailto:[e-mail]>>, Lombardo, Jeff <[e-mail]<mailto:[e-mail]>>, Patrick White <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] Re: [agent2agent] Re: Re: Review of draft-rosenberg-oauth-aauth-00

EXTERNAL: Use caution when clicking on links or opening attachments.


Having an agent obtain information about the user to authenticate to the AS smells like a bad idea and a conflation of concerns, breaking the security principle of separation of concerns.

How an OAuth flow happens where the user is authenticating to the AS over non web communication channels such as IVR does sounds like work for OAuth, not unlike the the Device Authorization Grant (RFC 86280 https://datatracker.ietf.org/doc/html/rfc8628

/Dick

On Thu, Jul 24, 2025 at 10:55 AM Leonard Rosenthol <lrosenth=[e-mail]<mailto:[e-mail]>> wrote:
Agreed that PII is not a good thing to pass around – however, that doesn’t necessarily preclude passing around “human and organizational identity” in a format that can be used to determine authentication and/or authorization. This is important in uses cases where the “endpoint” (tool, agent, service, etc.) is basing that decision on the human/org and not on the bot itself.

Leonard

From: Nick Watson <nwatson=[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 24, 2025 at 1:49 PM
To: Lombardo, Jeff <jeffsec=[e-mail]<mailto:[e-mail]>>
Cc: Patrick White <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [agent2agent] Re: [OAUTH-WG] Re: Review of draft-rosenberg-oauth-aauth-00

EXTERNAL: Use caution when clicking on links or opening attachments.


RFC 9728 already provides a lot of natural language descriptions of resource APIs - what would scope descriptions add over that?

I agree with Jeff that CIBA + RFC 9728 seems like it would address this, and we should avoid agents' passing PII around as an authn mechanism.

On Tue, Jul 22, 2025 at 7:52 PM Lombardo, Jeff <jeffsec=[e-mail]<mailto:[e-mail]>> wrote:
The scopes to be defined that still can be an AI agent role based on the task at stake. There is no issue with that cause the scopes have to be provided on the Authorization request to the AS.

My problem is the authentication flow going through the Agent and being based on PII. I would prefer an Out-of-Band Authentication if possible, and if not at least a dynamic authentication.

In this case, event a battlecard authentication would be better than a PII “authentication”, like the AS asking through the Agent give A-9, D-16, and E-4 for the user to retrieve the corresponding answer from its secret sheet.

The flow for OOB [which is exactly CIBA] would like in a picture:

[cid:image001.png@01DBFD91.19CEA560]

Here is a Mermaid link to the live Editor: https://mermaid.live/edit#pako:eNqlVu9v2jAQ_VdO_rJOY1XapYVEVaeO7kO_TAj2Q5qQKpMcwapjZ45Txqr-7zs7YYUQYNP6qYnv3r17fnfkiSU6RRazEn9UqBK8FTwzPJ8qoL8RN1YkouDKwo0UCe55_aqEm8ouUNFrboVWcIuPneGTqii0obQ7uMkovo6Y6Z8eQBvxq86foHlEU5-2MYZSUCaMMROlNXX8R5UWWqzxdkhuYR-O_awfsB1DT7utjLHUlUlwi6uX4-rq7dvr64PKxHUkiBKM7wMNpkDHFAupD4G5Nv6RF4VssusibRHreodkievEFuWGZ6c4cTvYUS2MtphYYjpbHbiwTxQF2uW0mcY7bxxswgs-k5Qyhw0Vidqb3fyr0efJJ1BVPkMjVHZ9vKJInfpzQYe5yBYWZk5hIx6pjbnROeRoecotr5-c4gmXsgdSPCCsdOUfKao-501xuIMHpZfdN-K4-yZi-IYy0ZRsNZCcdMVSKFdBEcCCP_oKZoPk-6MS3AHPN8fxUPEFt02tVHtDuX6sTvnqb-osnc-JuEGFS8hXZAAsEyMKf-V0XUKVFfVz_BJuveBQJrrAshbSuI1T2uO5Q4OcTjmMRbJo2W68CdIpxB53N6Dbxw0lWAq7gMTP071Ie0BgSBNFhqkbIG_oTKj7BUHBiZfwdSNnZ7lufW8SZyCJaYa5m4QTTsn3xIFqNnBS6wK-kDMk8E6mbnq0Kikd05d91iXE9l6LYaTJ1NsvvUHmUi8JMy8kvmwcXC_A_f0dWXcTggClncebEy9ySrMnZAknXtjei-ivN-y5D3XD6COJvMTNMGz5-9g63sgk2d3Ir_6NQmPF9X3QcnKj4_vywv5p7d-IDWs4h-XW0HqC9gAe5LlnFL5yKdLdYTg6Wv_lqO247gEZo62MakIneIBK67eKuKCh0rQmR3cwdLp5t203-AG5oYXj4VmP5WhyLlL6FnpyhaaMZMxxymL6N8U5r6Sdsql6plCaRT1ZqYTF1lTYY0ZX2YLFcy5LeqoKp2bzIfXnLX0zfNc6X6dkxpVq0mk20Ax1pSyLw7NB4KNZ_MR-svjsXXgaBYP-xXkYnoXB5flFj61YPIhOg4soiPrnURC8i4LL5x775fGD00E_jKKoH52F4eDysh8-_wa4dWW_

Here is the Mermaid for those who could not see the picture nor use the link:

sequenceDiagram
    Participant Alice
    Participant Alice's Authentication Device
    Participant Support AI Agent
    box Authorization Server
        Participant Client Registration Endpoint
        Participant Authorization Endpoint
        Participant Token Endpoint
    End
    Participant Resource Server
    Alice<<-->>Alice's Authentication Device: Alice is registered on the device for the application
    Support AI Agent<<-->>Client Registration Endpoint:
    Resource Server<<-->>Authorization Endpoint: Resource Server is protected by Authorization Server
    Note over Support AI Agent: Support AI Agent is capable of
    Alice->>+Support AI Agent: <PTSN numbering>
    Note over Support AI Agent: identifier might be derived from metadata from the call, like you call me from a number I know
    Support AI Agent->>+Alice: Welcome to our online can I have your identifier?
    Alice->>+Support AI Agent: I am Alice
    Support AI Agent->>+Alice: What can I do for you today?
    Alice->>+Support AI Agent: I want to renew my prescription of insulin
    Note over Support AI Agent: Derive scopes from request
    Note over Support AI Agent: Create a Rich Authorization Request
    Support AI Agent->>+Authorization Endpoint: Create Authorization request with client_id, generated scopes, login_hint (Alice)
    Authorization Endpoint->>+Support AI Agent: Acknowledgement (auth_req_id)
    loop Until authorization request is consented
        Support AI Agent->>+Token Endpoint: Poll Token Endpoint for flow completion
    end
    Authorization Endpoint->>+Alice's Authentication Device: Send notification with details (scope, client_id)
    Alice's Authentication Device->>+Alice: Please Authenticate
    Alice->>+Alice's Authentication Device: Authenticate locally
    Alice's Authentication Device->>+Alice: Request consenting to scope for client_id
    Alice->>+Alice's Authentication Device: Consent to all scopes for client_id
    Alice's Authentication Device->>+Authorization Endpoint: Validate Authorization Request
    Support AI Agent->>+Token Endpoint: Poll Token Endpoint for flow completion
    Token Endpoint->>+Support AI Agent: Return Token Set
    Support AI Agent->>+Resource Server: Perform API Call with Authorization Bearer Token


Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
( [phone]<tel:(514)%20778-5565>
Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

From: Patrick White <[e-mail]<mailto:[e-mail]>>
Sent: July 22, 2025 7:09 PM
To: Lombardo, Jeff <jeffsec=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Lombardo, Jeff <[e-mail]<mailto:[e-mail]>>
Subject: RE: [EXT] [agent2agent] Review of draft-rosenberg-oauth-aauth-00


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

Hey Jeff, someone pointed out the OIDC HITL spec here, there's absolutely some overlap, but one of the big things that missing is natural language descriptions of scopes (well, and also that it's not an oauth flow, but I'm not sure how much that matters). At a high level, a really important part of the AAuth stuff I proposed is tooling to allow the LLMs to actually discover what scopes they need. You could do it as part of a dance (I make a request, get the scope demand, then flow that through), but I was trying for a model where the models themselves would craft the scope request based on the well known scope definition document. Maybe I missed something around natural language scope definitions in the OIDC spec, though

On Tue, Jul 22, 2025 at 7:01 PM Lombardo, Jeff <jeffsec=[e-mail]<mailto:[e-mail]>> wrote:
[+ OAuth WG as this touches their core specs]

Thanks Jonathan and Pat for putting that forward.

Here are some comments / questions / suggestions:


  *   The use cases are very clear and are very good thought experiments to rubberstamp / challenge the models of delegated authorization we have build so far



  *   Unfortunately, the proposition seems to point towards a glorified Knowledge Based Authentication (KBA) as it will use PII validation to authenticate  as a form of “password” in a glorified Resource Owner Password Grant type flow as the request is only dealing with the Token endpoint… the problems are:

     *   Knowledge Based Authentication is highly insecure cause anyone that knowing this static information can impersonate someone else
     *   It is based on PII which are Identifiers and not Authentication factors, therefore can only allow to identify someone. On top of that, PII leak constantly and are no longer considered secure

        *   Also what would prevent the AI agent to fetch those information from the internet on behalf od the user as you noted into section 3.1. <https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth#section-3.1> Basic Token Flow<https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth#name-basic-token-flow>

By altering the required set of PII elements, designers of AI Agents can control the likelihood of hallucination (or malicious prompt injection attacks) resulting in a token issuance for the wrong user. The selection of the information becomes even more important for AI Agents. Usage of PII elements which are known publically becomes a real risk. If these are included in the training data for the LLM, it is indeed possible (and likely) that the LLM would hallucinate it. For example, if the patient in question is a famous actor, and their date of birth is public record in the IMDB, it is likely that the LLM would hallucinate the date of birth. Consequently, the Authorization Servers can be configured to require sufficient number and complexity of PII in order to provide the desired level of security.


        *   This hardly advocates for the PII to not flow through the AI cause thinking the AS will be smarter than the AI by configured to require sufficient number and complexity of PII in order to provide the desired level of security is a false expectation


     *   Resource Owner Password Grant flow is obsolete and deprecated see https://www.rfc-editor.org/rfc/rfc9700.html#name-resource-owner-password-cre



  *   Without consideration about the above points we are exchanging an AI Agent risk by a very secure AI Agent that could on very misleading / spoofable / malicious crafted information. I don’t think this better.



  *   Have you evaluated Client Initiated Backchannel Authorization grant type flow [  https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html ] before designing this new specification?

     *   This would perfectly fit into the following specification statement in section 3.2. <https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth#section-3.2> Human-In-The-Loop<https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth#name-human-in-the-loop>

Initiate the consent review flow with the user. This spec does not specify how this occurs, it could be through an app, a chat client, or some other mechanism.

My 0.02 Canadian Dollars

Jeff

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
( [phone]
Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

_______________________________________________
agent2agent mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>