The process:

The Resource Owner (RO) controls the "life cycle" of their resources. The management of an actual "resource" (create, read, update, delete) is out-of-scope for the User Managed Access (UMA) specification. The Resource Server (RS), from an UMA perspective, enables the Resource Owner (RO) register resources and apply policies. The Resource Server (RS) will enforce Requesting Party (RqP) access to the resources. Requesting Parties (RqP) will only be allowed to perform operations against resources that have a proper policy.

This Reference Implementation uses an external Content Server (CS) to manage actual resources / documents. The management of actual resources / documents could be provided as an embedded capability of the Resource Server (RS).

This sequence covers the process related to a Resource Owner (RO) that creates a resource (document) using a custom Resource Owner Application (ROA). The ROA optionally uses an external Content Server (CS) to store the actual document/resource. The ROA creates an associated resource in the Resource Server (RS). The Resource Server (RS) creates an associated meta data resource record, registers the resource with the Authorization Server (AS) and applies a policy to enable Requesting Parties (RqP) to perform certain operations (scopes).

The sequence:

• Resource Owner (RO) must be authenticated with the Authorization Server (AS)
  • This can be done prior to accessing the Resource Owner Application (ROA) with SSO Session or via an explicit login process
• Resource Owner Application (ROA) issues a POST request to the Resource Server (RS) /manage/resources interface to create / register / set policy and create content for the resource
  • The request contains required and optional attributes that are used to perform operations.
• Resource Server (RS) creates the resource and set meta data:
  • The user is validated
  • The initial resource records is created, setting meta data
• Content Server (CS)
  • If the request contains content (JSON), it is saved and the content id is returned
• Resource Server (RS):
  • The registration process requires a Protection API Token (PAT). The PAT represents a authorization trust between the Resource Owner (RO), Resource Server (RS) and the Authorization Server (AS). See the Resource Owner: Acquire PAT sequence diagram for details.
  • Perform POST operation to the Authorization Server (AS), using the PAT, to register the resource. The registration process defines the "name", "type","icon_uri" and allowed scopes. An Authorization Server (AS) identifier is return along with a URI for an interface to manage the resource.
  • The resource meta data is updated with the attributes returned from registration process. The resource state is set to "registered".
• Resource Server (RS) applies a policy to the resource
  • To enable the "sharing" of a resource, a policy must be applied. The policy is a collection of permissions that declares which Requesting Parties (RqP) can perform what operations (via scopes). More than one Requesting Party (RqP) can be contained in a collection of permissions and each subject, in the collection, can have a different set of scopes.
  • Perform a PUT operation to the Authorization Server (AS) update the policy for the Resource Owner (RO)
    • Note: The resource policy, can be managed with the with the Access Manager interface, by the Resource Owner (RO)
• Resource Owner Application (ROA) receive response from create operation
  • The interface is updated with the created resource