# Secondary use cases

iSHARE Trust Framework's [three primary use cases](https://framework.ishare.eu/version-2.1/detailed-descriptions/functional/primary-use-cases) are supported by seven secondary use cases. These include:

* Processes related to registration;
* Processes that recur in primary use cases.

#### **Processes related to registration** <a href="#secondaryusecases-processesrelatedtoregistration" id="secondaryusecases-processesrelatedtoregistration"></a>

These four secondary use cases need to be completed before any, or specific, primary use cases can be initiated.

**Any party** needs to:

{% hint style="success" %}
1a. Register adherence/certification in the Participant Registry

and later needs to be able to:

1b. Modify adherence/certification in the Participant Registry
{% endhint %}

Before initiating Human to Machine use cases, the **Service Consumer** needs to:

{% hint style="success" %}
2a. Create Service Consumer and/or Human Service Consumer identity at Identity Provider Prerequisites:

* An agreement needs to be in place between Service Consumer and Identity Provider;

later, a Service Consumer needs to be able to:

2b. Modify Service Consumer and/or Human Service Consumer identity at Identity Provider
{% endhint %}

When delegating rights, the **Entitled Party** needs to:

{% hint style="success" %}
3a. Register delegation at Service Provider, Entitled Party, or Authorization Registry Prerequisite:

* For registration at Service Provider or Authorization Registry, an agreement needs to be in place between Entitled Party and Service Provider or Authorization Registry.

later, an Entitled Party needs to be able to:

3b. Modify delegation at Service Provider, Entitled Party, or Authorization Registry
{% endhint %}

When authorizing something or -one, the **Service Consumer** needs to:

{% hint style="success" %}
4a. Register authorization at Service Provider, Entitled Party, or Authorization Registry Prerequisite:

* For registration at Service Provider or Authorization Registry, an agreement needs to be in place between Service Consumer and Service Provider or Authorization Registry.

later, a Service Consumer needs to be able to:

4b. Modify authorization at Service Provider, Entitled Party, or Authorization Registry
{% endhint %}

#### **Processes that recur in primary use cases** <a href="#secondaryusecases-processesthatrecurinprimaryusecases" id="secondaryusecases-processesthatrecurinprimaryusecases"></a>

These three secondary use cases form the wiring of all primary use cases. Without them, primary use cases cannot be completed successfully.

In any primary use case, **any party** needs to:

{% hint style="success" %}
5a. Check whether its counterparty is iSHARE adherent/certified (with the Participant Registry)

5b. Check whether its counterparty’s certificate is valid
{% endhint %}

In any primary use case, the **Service Provider** *also* needs to:

{% hint style="success" %}
6\. Determine an authorization decision based on entitlement-, delegation-, and/or authorization info in its own contract administration and/or from external PIPs
{% endhint %}

When delegation- or authorization info is requested by a Service Provider, an **Authorization Registry** or **Entitled Party** also needs to:

{% hint style="success" %}
7\. Determine authorization decision based on Service Consumer assertion included in Service Provider’s request
{% endhint %}

{% hint style="info" %}
Please note that the secondary use cases will not be detailed more than the above. No depictions or sequence diagrams are to be developed (contrary to for the primary use cases). This (deliberately) leaves freedom in implementation. This specifically accounts for the registration of delegations: the way in which delegations are registered (as policies, business rules, in a separate register, or on top of existing applications) is not defined.
{% endhint %}