I have some experience with previous AWS IAM policy language and evaluation, but not cedar directly. Some context that might help: C2a: think of the use case a

I have some experience with previous AWS IAM policy language and evaluation, but not cedar directly. Some context that might help: C2a: think of the use case around a centralized policy & identity store with lots of independent services consuming that. The services dont know or care how individual users create/store/update their policies. Nor how other services perform authorization. Each service is the only source of truth for that services requests, and must supply the necessary API request context etc. C2b In addition you could certainly build a “cedar service” that owned identity policy and identity context then joined that with the services context to perform the access evaluation. C2c: Conversely if your service is much more monolithic, with no central trust or trusted peers, you could do all of the above inside your mono-service. But batteries are not included here. C3: I actually dont know how to feasibly accomplish this with a capability based system. As youve mentioned authorization is very dependent on context, which is typically dynamic. Eg it might include time checks, source/dest network address, or even things like the machine identity that sent the request. It seems youd need to populate all the potential context to perform an evaluation, and a simple index/enumeration doesnt fit. Very interested if you have counter examples.