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

[Aaron Parecki <[e-mail]>]

CIBA literally has a section heading called "OpenID Provider Obtains
End-User Consent/Authorization"

On Thu, Jul 24, 2025 at 3:11 AM Dick Hardt <[e-mail]> wrote:

> CIBA does not address how to obtain consent
>
> On Thu, Jul 24, 2025 at 11:34 AM Lombardo, Jeff <[e-mail]>
> wrote:
>
>> Jonathan –
>>
>>
>>
>> I never questioned the use case (present and future with AI Agent) nor
>> the nature of  security / insecurity of the present use case.
>>
>> I only provided feedback on the proposed approach to the future state use
>> case, not to say it will never happen, but it should not happen as proposed.
>>
>>
>>
>> I hope me providing a flow diagram was a good expression of this respect.
>> If this was unclear, my apologies and I hope this statement makes it
>> clearer.
>>
>>
>>
>> *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:* Dick Hardt <[e-mail]>
>> *Sent:* July 24, 2025 11:27 AM
>> *To:* Jonathan Rosenberg <[e-mail]>
>> *Cc:* Lombardo, Jeff <[e-mail]>; Patrick White <
>> [e-mail]>; [e-mail]; [e-mail]; Lombardo,
>> Jeff <[e-mail]>
>> *Subject:* RE: [EXT] [agent2agent] 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.
>>
>>
>>
>> Note that CIBA is authentication rather than authorization.
>>
>>
>>
>> On Thu, Jul 24, 2025 at 11:14 AM Jonathan Rosenberg <[e-mail]>
>> wrote:
>>
>> Jeff -
>>
>>
>>
>> This message got stuck in the approval filter for agent2agent because it
>> was too large. I've just approved it and see it now.
>>
>>
>>
>> Thanks for your comments, and your pointer to CIBA as a potential
>> solution.
>>
>>
>>
>> For the use cases I am interested in, the end user likely doesn't have an
>> authentication device, or even if they do, they may not be able to access
>> it. Let me give you a concrete use case to help illustrate my problem.
>>
>>
>>
>> A user Bob is a truck driver, finishing his drive for the day. He wants
>> to book a low cost motel to stay for the evening. While driving, he places
>> a call (using the hands-free capability of the truck for the voice
>> conversation). Bob is connected to an AI agent, and he discusses with the
>> agent a local motel and what is price is. He is doing this through (for
>> example) Wyndham, which he has an account on, though he doesn't have the
>> wyndham app on his iphone nor can he look at his mobile phone while
>> driving. The AI Agent wants to book the room on his behalf with the
>> reservation API employed by Wyndham. The AI Agent needs an access token to
>> do so.
>>
>>
>>
>> This is a good example of my use case.
>>
>>
>>
>> TODAY - the way this works - like it or not (and I suspect your answer is
>> NOT) - Bob speaks to a live human being. The live human being requests some
>> identification information for the user - name, email, perhaps DOB, and
>> based on that, uses the reservation system to create the reservation. The
>> human contact center agent is logged into the reservation system with their
>> account as an employee of Wyndham. This account has high privelge, allowing
>> them to make reservations for any user in the system. This is how most call
>> centers work today.
>>
>>
>>
>> As we have moved that into bots, the pre-genAI versions worked quite
>> similarly; the bot has some kind of service account in the reservation
>> system, much like the human agent did. The bot identifies the end user
>> using PII, much like the human agent did. Then, the bot would make the
>> reservation using its access token - associated with the service account  -
>> much like the high privilege human user did. As we now move to LLM-powered
>> AI agents, the current trajectory is to continue to use these high
>> privelege tokens because they enable these use cases. I am trying to find a
>> solution wherein can do this with a lower privilege token.
>>
>>
>>
>> I certainly recognize the troubles of passing PII and am aware that this
>> is similar to the Resource Owner Password Grant flow which is now
>> deprecated. I like the CIBA flow  - and when it can work, it is clearly
>> superior to collection of PII by the AI Agent. And there are many use cases
>> where it can work - for example a user accessing the hotel through the
>> website while seated at their desk, having already logged into the website.
>> But in my use case above, I dont see how the CIBA flow can work.
>>
>>
>>
>> Thx,
>>
>> Jonathan R.
>>
>>
>>
>> On Thu, Jul 24, 2025 at 10:19 AM Lombardo, Jeff <jeffsec=
>> [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:
>>
>>
>>
>>
>>
>> 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]
>>
>> *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]>
>> *Sent:* July 22, 2025 7:09 PM
>> *To:* Lombardo, Jeff <jeffsec=[e-mail]>
>> *Cc:* [e-mail]; [e-mail]; Lombardo, Jeff <
>> [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]> 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]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> agent2agent mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> agent2agent mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>