If the PDP decides to respond with AuthZEN response along with the obligation in the context.
Atul: Is it only in ALLOW or DENY response?
Michiel: Needs to be in the ALLOW use case - eg return a data base filter
Yes both possible
AlexB: Profile describes some normative obligations - stepup, notification, session termination, and custom
Atul: Is alerting the same as notification?
Could be - porposal leaves it open how its handled.
Atul: Thinking more like a SIEM alert - is that a same a notification?
Michiel: Custom should not be a type, rather a vendor namespaced
Atul: Should we include advice also?
No - should be added to context
Atul: Would like to see goto a URL as an obligation as ARAP/AROP is too complicated
You could have a webhook obligation etc
Decsion: Merge PR as is and then continue iterating
COAZ-MCP
AlexB: Agent identity should be out of scope. That is an OAuth problem. As long as we can reference token claims and map it then its not needed.
Michiel: We have OAuth profiles in the works - does that cover?
Atul: Increasingly decisions need to include the agent identity as well as the human identity. We can say its in the context somewhere but not standardize it. Would be useful to have a single place to put - where it comes from eg client_id of act. Some recognition in the OAuth WG to put the agent idenitfier. We either ignore it and let people define where it goes or we define the location in the context.
AlexB: It would be redundant
Atul: The token goes to the PEP not the PDP.
AlexB: The MCP server needs a token with the delegation etc in it
Jeff: That was a big early dicussions - how do we wrap more than the subject. You can put all the claims in the context. Data points maybe coming from places other than token eg CIMD which would be needed for policy. For identity of the agents - heavily debated in OAuth and WIMSE - should it be a client type or an instance. OAuth will remain at the functional level - not down to the instance level.
Atul: We may have to make decisions based on an agent instance. eg create a support agent instance for a specific ticket.
Atul: Workload AuthZ grant spec goes towards this
Jeff: There is enough existing spec
Jeff: If you have an agent which upgrades from library for 0.5 to 0.6 - knowing that is important to the decision
AlexO: Need to bind the instance to the task
Dave: Doing this with the bearer token
Jeff: Need for the OAuth mapping profile
Dave: Looking at putting the operator in the actor - for the service which runs, pull out the operator identity - then the PIPs got and resolve from that
AlexB: It is safe to rely on tokens as the underlying protocol requires
Decision: Point the threads at the OAuth profiles and try and align around those rather than requiring a context.agent field