Skip to main content

FPX Landscape

Foundational Knowledge​

FPX (Federated Privacy Exchange) is an expansive product that builds on many existing software standards. It is useful to have familiarity with:

Who are FPX Partners?​

FPX partners are an extension of the UMA 2.0 actors to add authentication and user anonymity to the network. They are:

  • Clients requesting access to resources (UMA 2.0)
  • Resource Servers offering resources (UMA 2.0)
  • Wallets acting on a user's behalf (FPX 2.0)

The following diagram represents the interaction points of the various Partners in relation to the FPX Authorization Server. More details related to each Partner component follow.

Figure 1: FPX Partners

Client​

An application that provides a service for end-users. An example might be an Immunization app that creates calendar events when immunizations need to be updated or a credit app that pulls in credit information and offers advice and access to your credit score.

Clients need the FPX Network to access user resources that may be stored across many services under different or isolated identities. They may also use the network to discover Resource Servers. Moreover, they may use the network to request standardized resource types, such as a credit score, and allow the user to determine which trusted and vetted Resource Server will provide that resource.

Client roles, responsibilities and actions​

  • Negotiate with the FPX admins for the right to request resource types and scopes (See Client Capabilities).
  • Track the resources and scopes they are approved to request, their OAuth client credentials, and the state of transactions as they proceed through the FPX network.
  • Store the access tokens and refresh tokens to resources in a secure manner, and understand how to refresh or renew access tokens once they have expired.
  • Request resources at Resource Servers using access tokens, storing and protecting any user data that is returned in a secure, auditable and responsible process.
  • Provide a web-accessible call-back URI.

Resource Server​

An application that has stored user resources, and a means of determining who users are. An example might be a bank with the banking details for a user, or a lab with medical resources.

Resource Servers use the FPX network to broadcast their resource capabilities to clients who can use those resources to provide services to users. Resource Servers want a trusted way to allow their users to control who has access to those resources.

The FPX network will allow only vetted clients to access resources, and only with a user's consent.

Resource Server roles, responsibilities, and actions​

  • Negotiate with the FPX admins for proper rights to provide resources and which scopes they will offer to Clients.
  • Negotiate with FPX if necessary to protect user-specific resources through UMA 2.0 federated authentication (User PAT negotiation, Resource Protection).
  • Negotiate with FPX if necessary to protect ambiguous resources, which resolve users through a ROT, through UMA 2.0 federated authentication (Resource Server PAT negotiation, Resource Protection).
  • Track which resources belong to which users, manage their PATs and ROTs, and have the ability to map requests to a set of resources and scopes as needed.
  • Handle client requests for resources both with and without valid access tokens, returning either a rejection, a permission ticket, or the resource depending on implementation.

Wallet​

An actor introduced as an FPX extension of UMA 2.0. Wallets represent users in the network and prevent the Authorization Server (AS) from seeing and controlling user resources, sensitive data, and policy decisions.

The Wallet acts on the resource owner's and requesting party's behalf in the network. Some Authorization Server responsibilities in UMA 2.0 are delegates to a Wallet application, such as claims gathering and policy setting. This simplifies the Authorization Server to only handle communication, application-level permissions, and networking, while the Wallet handles secure information and user interactions.

The Wallet must attest to users' authenticity and right to participate in the network. They may do so through their own Identity Proofing, or delegating it to external IDPs such as a trusted bank.

Wallet roles, responsibilities, and actions​

  • Negotiate with an FPX network to be trusted to attest to and represent users.
  • Authenticate users (via federation), providing the account to any user who wishes to protect their resources through the network.
  • Represent the user during transactions, protecting their tokens and confidential data, and providing users a place to manage their permissions and connections to partners within the network.

Can partners act in more than one role?​

Many applications may act as both Clients and Resource Servers at different times. A bank may request your credit history in one transaction but store and provide access to financial statements in another. A government entity may provide the initial identity proofing to a Wallet but also act as an RS if they expose additional citizen resources to the network.

When the same application wishes to act in multiple roles, they should use unique client IDs for each role.

Partners may even act in multiple roles during the same transaction. A hospital may request lab results from a patient, only for the patient to use the same hospital to fulfill that request.