From the docs... > If your permissions checks are between machines or services and other services, it is recommended that the subject type be a representation of that service or its means of providing its identity. Why is this? We are currently considering using a common "principal" type to ensure semantics are consistent b/w services and users (and that supporting services isn't something clients have to think much about – just continue to parse JWTs and construct access checks the same way). Just wanted to see if there were any gotchya's we weren't thinking about.

i'm guessing it's a security thing - ime a service is going to have much broader permissions and access than a user across a certain set of relationships, and there are certain things that a user should be able to do that a service should never be able to do and vice versa

Ah I see. I'm talking about the latter – looks like a user, external/third party service interacting with our API

i think the comment in the docs is about internal services, where something like a service worker or batch job is making modifications to the system. i think what you're doing with a "principal" external to the system makes sense to me, especially if you've already considered things like audit etc.