The PARC Information Model
\
The PARC authorization model is a framework for making authority statements using four core components: Principal, Action, Resource, and Context. In English, this corresponds to the question:
“Can this principal take this action on this resource in this context?”.
The simplicity and flexibility of the PARC model, which is the basis for some of the largest authorization systems in use today, allows for expressing many types of authorization policies including Attribute-Based Access Control (ABAC), Role-Based Access Control (RBAC), and Relationship-Based Access Control (ReBAC).
§Principal
The principal is the entity that is the object of the authority statement, i.e., the entity whose actions the authority statement permits or denies. In the general PARC model, the principal could be a user, a group, a role, or another service or API.
In the context of TRQP, a principal is usually:
§Action
The action is the specific operation or verb the principal is permitted to perform. When the PARC model is applied to access control, examples include read, write, delete, or view.
In the context of TRQP authorization statements, example action values might be:
issue
verify
revoke
In the context of TRQP recognition and delegation statements, where the principal is another authority, example action values might be:
recognize
parent-of
child-of
§Resource
The resource is the object, data, or entity that the principal is permitted to act upon. With PARC-based access control, typical examples are a file, a database entry, or an API.
In the context of TRQP authorization statements, example resources might be:
credential type IDs
trust registry IDs
In the context of TRQP recognition and delegation statements, the resource would be the governance framework ID or ecosystem ID being recognized or being delegated to/from. The Resource (and Action) values indicated must align with the delegation approach used in the governance framework.
§Context
The context specifies constraints or conditions that must be met for the policy to apply. With PARC-based access control, typical examples might be the time of day, the network IP address, the principal’s group membership, or attributes of the resource itself.
When the PARC model is used within the scope of a single authorization system (such as for access control within a company), context is optional because the authority for the policies can be assumed. The opposite is true of TRQP: as a decentralized trust registry query protocol, context must be supplied in the form of the authority ID of the authority responsible for the authority statements being queried.
A TRQP query may also include other context parameters, such as time, as specified in section TODO.
§Context Objects
This section is normative.
In the PARC model, a context object is used to assert conditions that must be satisfied in order for an action to be permitted. As defined in section TODO, a TRQP query the authority_id is the primary context. Further refinement of the context is possible using an optional context parameter.
the use of authority_id above is confusing.
the requirements here are better handled in the Identifiers area?
Other than this required parameter, in a TRQP query:
A context object is OPTIONAL.
If included, a context object MUST be a JSON object whose members convey other conditions.
If a context object includes a time value: a time-based condition:
The time parameter MUST be expressed using a time member whose value is in RFC 3339 format.
The value of the time parameter MUST be interpreted as the datetime as of which the target authority statement is valid.
TODO: DO WE NEED TO PUT REQUIREMENTS IN FOR locator?
Additional JSON object members specifying other conditions MAY be defined by TRQP profiles or bindings.