Access management

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 issuer and payee.

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.