Skip to main content

Key Terms/Glossary

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z​

A​

Access Token​

An Access Token is a credential that can be used by a Client to access APIs. The list of Access Tokens used throughout the system are:

Assurance Levels​

AAL (Authenticator Assurance Level)​

An Assurance Level, part of the NIST Special Publication 800-63. AAL represents the robustness of the authentication process itself, and the binding between an authenticator and a specific individual’s identifier.

IAL (Identity Assurance Level)​

An Assurance Level, part of the NIST Special Publication 800-63. IAL represents the robustness of the identity proofing process to confidently determine the identity of an individual. IAL is selected to mitigate potential identity proofing errors.

FAL (Federation Assurance Level)​

An Assurance Level, part of the NIST Special Publication 800-63. FAL represents the robustness of the assertion protocol the federation uses to communicate authentication and attribute information (if applicable) to an RP. FAL is optional as not all digital systems will leverage federated identity architectures. FAL is selected to mitigate potential federation errors (an identity assertion is compromised).

Authorization Server (AS)​

A server that protects, on a resource owner's behalf, resources held at a resource server. The Authorization Server makes policy decisions and issues Access Tokens to Clients.

Authorization Server (AS) Account​

An anonymous account at an Authorization Server. Accounts can only be registered at an Authorization Server by an end-user through a Wallet within the network. Authenticating to an AS account allows a user to create permissions during Claims Gathering and manage them.

Authorization Admin Server​

A service to configure and monitor the Authorization Server's default settings, partners, resources, scopes and other artifacts, in order to govern the network.

AS-First Flow​

The FPX extension to the UMA 2.0 Authorization Grant Flow. Clients may retrieve a permission ticket for resource types instead of concrete resources through the Authorization Server's Token Endpoint. Once the Client has a Permission Ticket, the flow follows the standard UMA 2.0 Authorization Grant Flow.

C​

Claims Gathering​

The purpose of the interaction is for the FPX Authorization Server and Wallet to gather information for authorization assessment of permissions. The information gathered directly at the Authorization Server, and is not visible, or returned, to the Client.

An example of claims gathering may be the authentication of the end-user to an AS account, proof of an established private key, ownership of any Resource Owner Token, or more granular claims gathering.

Client​

An application that will make requests for protected resources at various resource servers on a requesting party's behalf. The resource owner must authorize the requesting party before they can authorize a client to access resources.

Client Capability​

A resource definition and set of scopes that a Client has the right to request. A Client may bundle capabilities together into a Capability Ticket when they know which resources they will ask of a user at the same time.

A Client Capability may be expressed as:

C has the right to request X from Users

Client Capability Ticket​

A group of Client Capabilities that a Client has bundled together to request. This allows a Client to request multiple resource types at once by exchanging a Capability Ticket for a UMA/Permission Ticket.

Abstract representation of a set of Client Capabilities that a Client has the right to request. A Client may exchange a Client Capability at the Token Endpoint for a UMA/Permission ticket. This allows them to request access to multiple resource types without knowing which Resource Servers should ultimately provide the users resources.

A Client Capability Ticket may be expressed as:

C would like to request [X,Y,Z] from a User

I​

Identity Proofing​

The process of proving your identity to another entity. Examples of identity proofing can be in person, such as providing identification papers at a border crossing, or online, such as when you enter an email and password for an account or answer questions about your credit.

Identity Provider (IDP)​

A trusted third party Identity Proofing service that can uniquely identify end-users in their system. Identity Providers may vouch that they have identified the end-user at specific IAL levels. A Wallet may require end users to authenticate at an IDP before creating a Wallet Account or AS Account.

IDP Account​

An account at an Identity Provider. Before creating a Wallet Account or AS Account, end-users may need to authenticate to an IDP account, and the Identity Provider must be trusted by the Wallet.

IDP IDToken​

An OIDC id_token representing an IDP Account as well as the IAL/AAL they authenticated with. If an IAL/AAL is not provided, it is assumed to be the minimum possible value.

IDP Access Token​

An OAuth access token scoped to an IDP Account, returned after the end-user completes Identity Proofing with the IDP. This token allows the wallet to, at the minimum, access a Userinfo endpoint at the IDP

J​

JWT​

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. See RFC 7519.

O​

OAuth Client​

A Client as defined by Oauth 2.0.

An application which will request access tokens to resources on behalf of a resource owner.

In UMA:

  • A Resource Server has an OAuth Client relationship with the Authorization Server, as they need a PAT to act on behalf of the resource owner, introspect access tokens, and generate Permission Tickets.
  • A Client is an OAuth Client to the Authorization Server, as they need access tokens to protected resources at Resource Servers protected by the Authorization Server.
  • An Authorization Server has an OAuth Client relationship with each Wallet, as they will need access to permission sets created at the Wallet.
  • A Wallet may have an OAuth Client relationship with an RS, as they need access tokens and access to the resource owner's account there to share permissions and set policies.

OAuth Credentials​

The Client ID and authentication credentials for an OAuth Client as defined by Oauth 2.0. Credentials may take the form of a secret or public key agreed upon by both parties.

OAuth Redirect URI​

A specific redirect URI from the registered set of redirect URIs for an OAuth Client as defined by Oauth 2.0.

OAuth Provider​

The compliment of an OAuth Client, OAuth Providers issue access tokens for resources to an authorized OAuth client after validating the client and/or resource owner.

Resource Servers, Wallets, Identity Providers, and Authorization Servers act as an OAuth Provider to other entities in the FPX network. See OAuth Client for more information.

P​

Permission​

Authorized access to a particular resource with some number of scopes bound to that resource.
A permission grants a Client access to a resource on behalf of a Requesting Party

A permission includes a set of scopes to restrict access to the resource.

A permission may be expressed as:
X CAN ACT ON BEHALF OF U TO DO Y ON RESOURCE Z

Permission Ticket​

An unfulfilled UMA Ticket. It represents a set of resources and scopes that are in the process of being requested.

It may be generated by a Resource Server for their own resources, and given out to a Client in order to request access at an Authorization Server.

A client may also generate a Permission Ticket directly with the Authorization Server. In this case, the ticket is no longer coupled to a specific Resource Server. Instead it represents a generic request for various resource types and scopes, and can be fulfilled by a combination of Resource Servers that can provide the requested resource type(s).

Like all UMA Tickets, a Permission Ticket is only valid for use once at one endpoint, and is replaced by a new UMA ticket if more actions are needed by the Client.

Protection API Access Token (PAT)​

An OAuth access token with the scope 'uma_protection'. It is used by a Resource Server to access an Authorization Server's protection and introspection APIs.

When resources are registered at the Authorization Server for a specific resource owner, that resource owner must authorize issuance of the PAT to the Resource Server at the Authorization Server.

When resources are registered at the Authorization Server without a specific resource owner, the Resource Server will take on the role of the resource owner for issuance of the PAT. This means the Resource Server should request a PAT using its client credentials or a derived client access token.

Permission Pushing​

A Requesting Party pushes permissions to fulfill an UMA ticket for a Client. A Resource Server or Client requests a Permission, and after Claims-gathering the Requesting Party will push the permissions they wish to grant.

A pushed permission may be expressed as:

I GRANT X PERMISSION TO DO Y ON RESOURCE Z

Partners​

FPX Partners are an extension of the UMA 2.0 actors. They are:

R​

Resource / Protected Resource​

An abstract concept for something owned by a resource owner, controlled by a Resource Server, and protected through an FPX network. Examples might be data (SIN Numbers), an API (add new doctor to payroll), or more esoteric concepts.

A resource protected by an FPX network MUST include information such as a resource type and what scopes may be granted on this resource.

Both the terms 'resource' and 'protected resource' may be used to describe a resource protected by an Authorization Server.

Resources which are not protected by an Authorization Server will be referred to as unprotected resources.

Resource Server​

A server that hosts resources on a resource owner's behalf and is capable of accepting and responding to requests for protected resources.

Resource Server Account (RS Account)​

An end-user's account at a Resource Server. Just as the end-user is known at an Identity Provider by their IDP account, an end-user is known at a Resource Server by their RS account.

When an end-user authenticates to their RS Account during RS Linking, the Wallet will receive an RS IDToken representing this account as well as an RS Access token, which may be a PAT, to authorize the Wallet to act on their behalf.

RS Linking​

The process of a user authenticating to their data at a Resource Server and receiving access tokens and ROTs to both control and represent their data within an FPX network, respectively. An authorized Wallet will control those tokens on the user's behalf.

RS Access Token​

An Access Token scoped to a Resource Server. During RS Linking the Wallet will receive an access token that will allow them to create Resource Owner Tokens.

Resource Type​

Data and APIs often conform to standardized formats or specifications. All resources which conform to a specification are said to be the same "type" of resource. In order to improve interoperability between Resource Servers, each resource is registered in the FPX network with a specific Resource Type. The Resource Type is a URI defining the specification and use of the API.

For example, patient data from many Resource Servers may conform to the same FHIR Patient spec. Each of these "Patient" resources would be registered against the resource type http://hl7.org/fhir/Patient.html.

Resource types allow Clients to ask for more generic data, and have more confidence in how to process the data or API they get back.

Resource Definition​

A combination of a Resource Type, possible Scopes, and user info such as an icon and name. A Resource Definition allows the network to define a Resource Type and control what Scopes are allowed and which Clients and Resource Servers can use it. Resources can only be registered with scopes that are in the set of allowed scopes on the corresponding Resource Definition.

They provide an extra layer of control, limiting which resource scopes a Client can request or a Resource Server can provide.

Resource Owner​

A user or legal entity that is capable of granting access to a protected resource. Resource owners may delegate the ability to grant access to their resources to other entities.

The resource owner can, but is not required to be, the same entity as the requesting party during a User Managed Access Transaction.

During an UMA transaction, A Client can therefore be said to be seeking resource owner authorization to the resource owner's resources on behalf of the Requesting Party.

For example, Alice (Resource Owner) controls access to her calendar (Resource) but has delegated some rights to her spouse to be able to add new events to it. A doctor's office (Client) may seek Alice's (Resource Owner) authorization to create a new appointment (Access to Resource) on behalf of either herself (Requesting Party), or her spouse (Requesting Party).

Resource Owner Token (ROT)​

Resource Servers will issue Resource Owner Token(s) to a Wallet after authenticating the end-user.

Resource Owner Tokens offer a way to anonymously act as a new entity with every transaction. Resource Owner Tokens should be opaque to everyone but the Resource Server that issued them.

The format of a Resource Owner Token is left up to each Resource Server, however they must be resolvable, and SHOULD allow for proof of possession and non-repudiation of the transaction.

Each Permission granted by the user MUST specify a Resource Owner Token. If a new Resource Owner Token is used with every transaction, partners other than the Resource Server will be unable to link requests to the same user.
The Resource Server will use this token during introspection of access tokens to validate who the Requesting Party and/or resource owner are.

Requesting Party​

A natural or legal person that uses a Client to seek access to a protected resource. The Requesting Party may or may not be the same entity as the Resource Owner.

Requesting Party Token (RPT)​

An OAuth access token associated with the UMA grant. The RPT will represent a set of permissions granted by the Requesting Party.
Clients may exchange a fulfilled UMA ticket at the token endpoint for an RPT.

RS-First Flow​

The Standard UMA 2.0 Authorization Grant Flow. See User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization for details.

S​

Scope​

A mechanism to limit or augment a Client's access to Resources. A Scope may limit access ("read","write","admin","guest") to the entire API, the data returned ("name", "email", "SSN", "sensitivity4"), or encompass other concepts of resource access/restrictions in order to provide fine-grain granular control.

The Authorization Server will define the total set of Scopes for each Resource Definition.

The Authorization Server will define a subset of Resource Definition Scopes that a Client may request.

The Authorization Server may define a subset of Resource Definition Scopes that a Resource Server may create Resources with.

The Authorization Server must compare the permission scopes granted by the user against the scopes allowed by the client, the resource, and the requesting party to determine if that permission is valid.

T​

Ticket Resource​

An unfulfilled request for a resource type as part of an UMA Ticket/Permission Ticket. An UMA ticket may contain multiple Ticket Resources.

A Ticket Resource will contain a resource type, the scopes requested for that resource type, and optionally a resource that must be used to fulfill it.

If no resource is specified, the Requesting Party may use any resource from any resource server to fulfill the request, as long as it conforms to the resource type requested.

Token Endpoint​

An OAuth endpoint to allow OAuth Clients to obtain identity and access tokens by exchanging an OAuth 2.0 grant.

The grant is a recognised credential that can take many forms. A grant for an RPT may be a permission ticket and client credentials, a grant for a PAT may be client credentials or an Authorization Code. The grant_type parameter allows the Authorization Server to know what type of OAuth Grant the Client is presenting.

U​

UMA Ticket​

A representation of an ongoing UMA transaction at an Authorization Server.

Depending on the stage and type of the transaction, it may be a Permission Ticket, the UMA version of an OAuth 2.0 Authorization Code, or both.

If the requested permissions for an UMA ticket have been fulfilled, it can be exchanged at the token endpoint for access token(s). Otherwise, it can be exchanged at the Claims-Gathering endpoint to ask for additional permissions from the Requesting Party.

Once an UMA ticket is used at any endpoint, successfully or not, a new UMA ticket is created to represent the ongoing transaction and returned to the Client for further use.

User Managed Access (UMA)​

The base protocol that FPX is built on. UMA is an extension of OAuth 2 which defines:

  • a means for a client, representing a requesting party, to use a permission ticket to request an OAuth 2.0 access token to gain access to a protected resource asynchronously from the time a resource owner authorizes access.
  • a means for an UMA-enabled authorization server and resource server to be loosely coupled, or federated, in a secure and authorized resource owner context.

See the following specifications for details:

W​

Wallet​

An application that acts as the User's agent during transactions with an FPX network. They perform some of the user-specific duties of an Authorization Server, including claims-gathering, permission-pushing, and policy setting. Wallets have the most visibility into a user's data, and are responsible for holding and securing the tokens and identities that the user uses throughout the network.

Wallet Account​

An account at a Wallet that is controlled by the end-user. A Wallet Account allows the Wallet to protect and organize tokens and a user's identities, such as PATs, Granted Permissions, User data, AS accounts, IDP accounts, and RS accounts, in one place.