Authorization

Claim structure

When converted to an NPL claims object, the contents of a claim are always interpreted as a set of strings values, including the standard JWT reserved claims. Primitives that are not strings will be stringified, and empty claims will be removed.

All array nestings will be flattened, which means that the nesting of arrays does not have any significance and should not convey any information.

Note

The custom properties of the JWT are typically defined in the authorization context of the enterprise that is issuing it. Therefore, NPL derives claims from the existing structure rather imposing a specific schema on the JWT.

Warning

=> is a reserved character sequence and must never be used as part of a claim key or value in the JWT.

Protocol parties

Parties are the ultimate arbiters of how protocol instances and protocol data are used. Every NPL protocol instance requires the binding of party values, a step referred to as 'party assignment'. Assignments are made at the time of protocol instantiation.

An NPL party assignment consists of a set of key/value pairs, called claims, which are responsible for access control).

The claims' key/value pairs are of type Pair<Text, Set<Text>>, allowing multiple text value to be attached to each claim key.

Below is an example of what a party assignment may look like. For the moment all claims are optional. However, the iss claim is mandatory when using multinode.

Determining authorization

Claims specify what actions the party may take by giving the right to represent a given party or parties. Claims are a form of Attribute Based Access Control (ABAC).

How does authorization work?

Authorization ascertains the actual access rights. As explained above, requests for which the token's claims does not match are always rejected.

Authorization also uses the claims in the token. Specifically, for each of the claims in the party assignment, there must be a matching claim with the correct value in the token.

For a more technical overview of how claims are evaluated, see Claims Evaluation.

Examples

A party assignment limiting access to one specific user

It is possible to authorize only a specific user through a user-specific claim.

Single user claims :

{
  "claims": {
    "iss": ["http://www.noumenadigital.com"],
    "org": ["Noumena Digital AG"]
    "preferred_username": "Bill"
  }
}