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

[Nick Watson <[e-mail]>]

@Jonathan: I'm wary of codifying today's poor security practices. There are
numerous reports of people having their accounts "hacked" (e.g. airline
miles stolen), to the point where many of these call centers are
implementing 2FA with a code sent to your device.

In your example, as long as the driver has a device around, the gap can be
reduced to the user needing a hands-free way to interact with the device.
e.g. AS pushes a notification to user's device, user uses voice to confirm
it. (And this is an implementation detail of the out of band authz.)

Dick, while CIBA was written for authn, doesn't it work essentially as-is
for authz? It explicitly calls out that any scope is permitted, as long as
openid is included.

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

> 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] <(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]>
>>> *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]
>