Hi Michael, Thanks for sharing how you're tackling the same problem -- this is really helpful context.
Your approach at Atlassian lines up with a lot of the motivation behind the draft. The idea of a “profile owner” + “profile name” pair is especially interesting, along with the metadata model you’ve built around it. In your model, how should we think about the “profile owner”? Is it the entity attesting to the profile, the organization responsible for the agent’s behavior, or something else? I’d also love to understand a bit more about: 1) what metadata you associate with a profile today 2) how much of that metadata you think belongs in a standardized structure vs. vendor-specific fields 3) whether the “profile owner” concept generalizes well across ecosystems Also, when you mentioned CIMD's lack of unique registration, were you referring to not being able to uniquely register agent instances, or to something else? Thanks, Sreyanth On Mon, Nov 17, 2025 at 3:12 PM Mike Kuredjian <[email protected]> wrote: > 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] >> > -- *Sreyantha Chary M*
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
