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= [email protected]> 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 > > ( +1 514 778 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$> > *.* > > > _______________________________________________ > agent2agent mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
