NPL makes a clear distinction between conceptual access control when programming protocols through the use of parties and actual access control by tying these parties to your Identity and Access Management system (IAM).
For example, the IOU Example only refers to the abstract notion of
Only when instantiating an actual IOU do these parties get tied to Claims, which are essentially user attributes provided by your IAM.
When users (or other systems) interact with a protocol instance, they need to provide a token issued to them by the IAM. The Noumena Operating Engine then ensures that only the right protocols can be seen and that only the right permissions can be executed.
sequenceDiagram User->>Browser/FE: User logs in Browser/FE->>IAM: Login credentials IAM->>IAM: User authentication IAM->>Browser/FE: JWT token including claims Browser/FE-->>User: Login success Loop User Journey Note right of User: User navigates the frontend UI User-->>Browser/FE: Call to action (CTA) Browser/FE->>NPL Engine: API Call + JWT Token NPL Engine-->>IAM: Validate Token NPL Engine ->>NPL Engine: Validate access to protocol and permission NPL Engine->>NPL Engine: Execute permission NPL Engine->>Browser/FE: API Response Browser/FE-->>User: UI Response end
In short, when a user logs in and is authenticated via your IAM, a JWT including a user's claims is presented to the NPL engine each time an API call is initiated (by a frontend UI, for example). The engine will ensure that if a protocol instantiation or permission requires a specific party (e.g. someone working for Noumena in the Finance department as an Accountant) this will be verified before it is executed.
More information about the Operation Engine is provided under Authorization and Authentication.