Alastria ID flows

Subject Status and Transitions

A digital identity allows the user/subject to authenticate and present (certified) personal information in order to get a service, those actions require the creation and set-up of a digital identity and the gathering of certified personal information (credentials) from trusted sources.

For pseudonymous single usage, i.e. presenting some information in order to get a service where the Service Provider does not need to record anything and is not going to provide services in a recurrent way an Alastria Id is enough. Consider for example a user presenting a credential entitling to obtain a digital asset (photo, song, etc.) or access to a given place (building, conference center).

When authentication is required or, when recurrent service is going to be provided or when the service provider needs to record the presentation gathered, the Alastria Id could be recorded in order to make easier to provide the service or record interactions with the user.

For Credential Issuance linked to an Alastria Id, the Alastria Id must also be recorded by the entity.

Then to use Alastria Id in front of a given Entity (service Provider or Credential Issuer) the user Alastria Id is likely to be recorded by the entity. When there is another identifier used by the entity to identify internally the same user (Legacy Id), the Alastria ID and the Legacy ID should be linked together.

The different situations which are possible for the relationship between a subject and a given entity (Service Provider or Credential Issuer), depending on whether the user has an Alastria Id, a Legacy Id for that entity and whether the Alastria Id is recorded (and linked to the Legacy Id) by the entity.

All the possible situations are shown in a status table:

Status	Subject has Alastria ID	Subject has Legacy ID	Next status (Entity)	Next status (Other entities)
A	No	No	B	No change
B	No	Yes	E	A→C OR B→D
C	Yes	No	E	No change
D	Yes (unrecorded)	Yes	E	No change
E	Yes (recorded and linked)	Yes	No change	No change

An Alastria Id is ready for recurrent regular usage in front of an entity when in status E: Alastria Id recorded and linked to Legacy Id when required. Most entities currently identify users internally with a Legacy Id, we expect that Alastria Id can play that role in the future removing the need for a different Legacy Id at least for new users.

User Stories (US)

1. Alastria ID Creation (US-1.x)

Based on the previous status table, there are different User Stories related to the Alastria ID Creation, in order to reach status E, depending current subject/situation.

	User Story	Transition	Required Steps	UML Sequence Diagram	Detail
US-1.1	Legacy Onboarding	A→B	1. Legacy Onboarding	-	-
US-1.2	Alastria ID Creation	B→E	1. Legacy Authentication 2. Wallet Download 3. Key Pair Generation (Wallet) 4. Alastria ID Generation 5. Linking Alastria ID with Legacy ID	Link	Link
US-1.3	Onboarding with Alastria ID	C→E	1. Alastria ID Authentication 2. Presentation + [Legacy onboarding] 3. Linking Alastria ID with Legacy ID	Link	Link
US-1.4.1	Alastria Id Registration & Legacy Id Linking	D→E	1. Alastria ID Authentication 2. Legacy Authentication 3. Linking Alastria ID with Legacy Id	Link	Link
US-1.4.2	Alastria Id Registration & Legacy Id Linking	D→E	1. Legacy Authentication 2. Alastria ID Authentication 3. Linking Alastria ID with Legacy Id	Link	Link

2. Alastria ID regular usage (US-2.x)

The subject must always be in status E having both, Alastria ID and linked Legacy Id.

		User Story	UML Sequence Diagram	Detail
US-2.1 Alastria ID Authentication	US-2.1.1	Alastria ID Authentication	Link	Link
US-2.2 Alastria ID Credentials	US-2.2.1	Credential Issuance	Link	Link
	US-2.2.2	Credential Revocation	Link	Link
	US-2.2.3	Credential Query Status	Link	Link
	US-2.2.4	Expiring Credential	Out of MVP scope
	US-2.2.5	Credential Request	Link	Link
US-2.3 Alastria ID Presentations	US-2.3.1.1	Presentation Request	Link	Link
	US-2.3.1.2	Present Presentation	Link	Link
	US-2.3.2	Withdraw Presentation	Link	Link
	US-2.3.3	Presentation Query Status	Link	Link
	US-2.3.4	Expiring Presentation	Out of MVP scope

3. Alastria ID recovery (US-3.x)

		User Story	UML Sequence Diagram	Detail
US-3.1 Alastria ID Identity Recovery	US-3.1	Alastria ID - Identity Recovery	Link	Link

4. Alastria ID end of life(US-4.x)

Out of MVP scope

5. Subprocedures

		Subprocedures	UML Sequence Diagram	Detail
US-5.1 TinyURL subprocedure	US-5.1	Alastria ID - TinyURL	Link	Link

Identity and Private Keys recovery

Control keys replacement while having current keys

This is a useful option for replacing PrivKeyUser on a timely basis or if the private key is suspicious of not being secure. Identity Manager is able to change the link between old and new key, registering the key in the registry.

It is necessary to recover all the cyphered information in the user repository and re-cypher using the new public key. If the old Private Key is suspect of leak it is possible to request deletion mark on the associated public key.

Recovery of lost private and public keys.

There is an initial safekeeping and recovery of the user private and public keys.

Each key will be split in "n" parts (minimum of 3) so the key can be recovered with n-1 parts following Shamir Secret Sharing algorithm. The fragments will be cyphered with the user password and will be shared among n entities for safekeeping. These entities will be selected by the user from a whitelist of identity issuers, o that have issued a certain (to be determined) n credentials of level 2 or 3. In this case the user will be warned if there are less than 3 issuers that fulfil the condition.

Process

1. Key recovery will be done by the user using a new device with Alastria app installed.
2. Use off-chain legacy user identification, select Alastria key recovery option. i. Generate an Alastia Token ii. Send Alastria ID to the user and the fragment the SP holds
3. Repeat until recovering n-1 fragments.
4. Using those n-1 fragments Alastria mobile app will ask the user his password to recover and decipher the key pair, setting the in the secure enclave.

At this stage it is recommended to check if the public key matches in the registry. It is also recommended following the previous procedure to replace the lost key with a new one.

Complete loss of the keys

In case of loss of the private key, the identity manager is able to reset the link between the new key pair and the proxy contract (AlastriaID)

It is possible that this replacement can be made by a set of 3 or more issuers previously selected by the user from the whitelist of issuers. FNMT participation in Alastria may expand to other processes.

This way the identity is recovered but all the credentials are lost if there is no external backup