+1 to what was said.

Also from the few I read, there is tendency of Token overloading. We need to 
have consideration for CIMD to act a by reference instead of always going to a 
by value stance now.

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

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: Ayesha Dissanayaka <[email protected]>
Sent: March 17, 2026 12:37 PM
To: [email protected]
Subject: [EXT] [OAUTH-WG] Re: Overlap of AI related proposals


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.

I wasn't present at the meeting, but I'd agree with George's comment.

This is a brainstorming 
document<https://docs.google.com/document/d/1PhWC4KRO00kOPUW113ldG06Vii5dZjW3ljiV1tA0GCc/edit?tab=t.0>
 we developed at CG-AIIM in the early days to frame the overall agent IAM 
problems. It's not evolved for the recent developments, but it has some essence 
for the need to identify the problem domain broadly and to have a holistic view 
of

  1.  Where can we apply existing standards and best practices?
  2.  Where do we see problems that existing solutions cannot address?
  3.  Where do we extend or innovate?
Happy to take part in further conversations on the topic.

On Tue, Mar 17, 2026 at 9:04 PM Vladimir Dzhuvinov | Connect2id 
<[email protected]<mailto:[email protected]>> wrote:

I'm writing to +1 the spirit of this comment.

There is prior art, existing specs that distill knowledge how to solve classes 
of problems in the authorization space. It was exciting to read some the 
proposed drafts, but I also constantly thinking - what do we have already, can 
there be more generic solutions to these problems.

Vladimir Dzhuvinov
On 16/03/2026 14:55, 
[email protected]<mailto:[email protected]> wrote:
On Monday at the OAuth meeting for IETF 125 a number of AI related proposals 
were made to extend existing OAuth mechanisms in different ways. However, it 
seemed to me that there was overlap in the desired goals across these proposals 
and I’m wondering if for the AI space we need to take a step back and define 
the desired requirements before making spec level proposals. Just in what was 
presented, there is fragmentations and this doesn’t include a number of other 
proposals that have been made (either to IETF or otherwise) but were not 
presented.

General topics that seem to come up frequently:
* identifiers - instance, owner, version, …
* fine-grained authorization - RAR, scope extensions, transaction tokens, …
* delegated authorization - delegation chain, delegation capabilities, 
on-behalf-of, for-the-benefit-of, …
* context & intent - transformation of original intent for specific delegation 
task, ...
* consent - levels of delegation before consent is required, back channel 
consent, …
* privacy -

I’m sure there are more. I know it takes more time, but I believe we should 
address these issues holistically rather than on a spec by spec basis.

Thanks,
George

George Fletcher
Identity Standards Architect
Practical Identity LLC






_______________________________________________

OAuth mailing list -- [email protected]<mailto:[email protected]>

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

Reply via email to