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
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:
- Requesting Party Token (RPT)
- Permission Access Token
- Protection API Access Token (PAT)
- IDP Access Token
- RS Access Token
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)
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
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.
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.
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.
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
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 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
A Client as defined by Oauth 2.0.
An application which will request access tokens to resources on behalf of a resource owner.
- 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 Redirect URI
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.
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
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)
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.
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
FPX Partners are an extension of the UMA 2.0 actors. They are:
- The Clients requesting access
- Resource Servers offering resources
- Wallets acting on behalf of users and and vouching for their authenticity.
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 Account (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.
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
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.
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.
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.
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 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 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.
The Standard UMA 2.0 Authorization Grant Flow. See User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization for details.
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 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.
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.
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.
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:
- User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization
- Federated Authorization for User-Managed Access (UMA) 2.0
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.
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.