Specific pseudonym

The specific pseudonym is unique for each different combination of user, represented service consumer, intermediary and service provider.

 It can be created in two ways:

1. In the event of representation by an MR

2. In the event of non-representation by an AD

A specific pseudonym is preferably generated once and then stored, but it can also be generated for each request as long as it is always generated in the same way and the same value is generated for each request.

Differences in specific pseudonyms can be used by service providers to determine that the users are different (four-eye principle). This is the reason why an MR MUST have permission to generate a new pseudonym for an existing combination of service provider, user and service consumer (or intermediary in the case of chain authorizations) from the authorization manager or legal representative of the service consumer (or the intermediary). Reasons to generate a new pseudonym can be:

• user has been assigned a new job in the same company and may therefore no longer obtain access with the old pseudonym to files at service providers that are linked to the old role;

• The identity of the user was accidently disclosed to the service provider(s) and a new pseudonym is needed to protect/pseudonymize the identity;

• Migration to a new pseudonym is needed because the service providers merged/split.

The format of the specific pseudonym MUST have a hexadecimal value of 32 byte. For example, ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890

In the event of representation, this value is followed by an @ and hexadecimal value of 16 byte. For example, ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890@ABCDEF1234567890ABCDEF1234567890

The 32-byte value MUST be a random value This can be achieved, for example, by calculating an SHA256 hash over the following elements (in this sequence and separated by a separator):

1. The service provider's OIN.

2. A unique (but not necessarily exclusive) identifying attribute for the user in the context of the service consumer. This attribute MAY be determined by the administrator or the creator of the pseudonym, but MAY also be the Internal pseudonym.

3. The identifying attribute for the represented service consumer (only in the event of representation without chain authorization) or for an intermediary (in the event of chain authorization).

Other methods to reach a 32-byte random value are also allowed.

The value of 16 byte MUST be an MD5 hash over the identifying attribute for the represented service consumer (or intermediary in the case of chain authorization).

Other formats of specific pseudonyms may be in use. Users of the specific pseudonym are advised not to use (parts of) the pseudonym for other purposes than to identify the user.