[+ 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$>.
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
