Hey Sreyanth, This is a very interesting draft that sort of pokes into the same pain points we experienced with agent registration and DCR, over here at Atlassian. The way we're going about solving this problem of identification does overlap with some ideas outlined, namely:
- Our clients are being "profiled", but not with the proposed standard; rather, we identify a "profile owner" and a "profile name", so something like, "ai.dcr3p", and pin that to the client as both an identifier and behavioural modifier - Our P/R gateway (api.atlassian.com) and it's aliases, allow for exposing specific P/R metadata, which allows them to make references to the A/S relative to themselves as a "profile owner" - The A/S understands how to parse the relative URIs and trace them back to a legitimate "profile owner" because they're registered as clients with that specific property - An agent with a relative P/R metadata document + A/S lookup will receive a "profile-relative" DCR URI in the A/S metadata document, which auto-magically categorizes them upon dynamic registration All this to say that we circumvent the main issue with CMID: lack of unique registration. I think it would be nice to expand your notion of a profile to encompass not just a scalar, "name", but also some type of metadata. Cheers! Michael On Fri, Oct 17, 2025 at 1:06 PM Sreyanth <[email protected]> wrote: > Hi all, > > Pam Dingle and I are proposing a new Internet-Draft: OAuth 2.0 Entity > Profiles ( > https://datatracker.ietf.org/doc/draft-mora-oauth-entity-profiles). > > This draft introduces a mechanism to categorize and describe the two key > entities in OAuth flows: clients initiating the flows and subjects (or > resource owners) represented in tokens. > > The draft doesn’t prescribe specific behaviors but instead provides > contextual metadata that authorization servers and resource servers can use > to make informed policy decisions. We envision that future OAuth extensions > and profiles could reference these entity profiles and define verification > and handling mechanisms for the entity profiles they target. > > The primary motivation stems from the emerging AI-agent scenarios, where > it’s becoming increasingly critical to know 1) when an OAuth client is an > AI agent, 2) when an AI agent is acting on behalf of another agent or a > human, and 3) how this context can be consistently represented and > interpreted in OAuth flows. > > We’d greatly appreciate the WG’s feedback and suggestions. > > Thanks, > Sreyanth and Pam > _______________________________________________ > OAuth 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]
