Allow self-vetting with self-asserted tokens

This issue is imported from pivotal - Originaly created at Jan 23, 2023 by Michiel Kodde

As an Identity I want to be able to self vet tokens using my self asserted token.

Some restrictions are present here.

The self-asserted token used to self-vet the token causes the self-vetted token to have a reduced LoA. The LoA (1.5) of the SAT token will also be applied to the self-vetted token.
The current authroization does not allow for using the self-asserted token for any self vetting. As the LoA of the SAT token can never satisfy the projected LoA of the self-vetted token. This must be taken into account when the user is in possession of a SAT token (and only when).

These scenarios hopefully describe the story to a more detailed extent.

Scenario 1: Given an identity with a self-asserted yubikey (LoA 1.5). Registers a second SMS token (LoA 2). The self-service application allows this token to be self vetted, or to be vetted at the RA desk. Resulting in a LoA 1.5 token when self-vetting is chosen. Or in a LoA 2 token when the user chose the RA vetting option.

Scenario 2: Given an identity with a self-asserted SMS and a RA vetted Tiqr token. When the idenity tries to register a third Yubikey token, it is presented with the options to: self-vet using the self-asserted token. Resulting in a LoA 1.5 yubikey. Or to RA vet the token, resulting in a LoA 3 token.

Additional functional details (summary of call with Peter & Pieter 2023-01-31 16:00):

When the self service - self vetting registration is triggered. The Identity is asked for a step up authentication (in GW) with the already registered token (I\'m calling this the authoring token from now on). This can either be a token registered at the service desk (on-premise) or be a self-asserted token.

When a ra-vetted token is used, the regular rules apply. The token that is self-vetted must be authrored with a LoA equal or highter to the one being registered.

When a self-asserted token is used, any self-asserted token will do, when it comes to authorizing the self-vet action. As long as the authoring token used was registered in a self-asserted registration.

When both self-asserted and ra-vetted tokens are in possession of the user, self vetting with a self-asserted token is no longer allowed.

The Gateway does not provide detailed information about the token used during a step-up authentication. Only the resulting LoA can be read from the SAML Response. So another means is required to determine if the user gave a step up with a self-asserted token.

In that regard, the existing authorization check can be used, that verifies if the Identity is allowed to register self-asserted tokens. If this results in a positive authorization, we can safely assume the user is only in possession of SAT tokens. Once a ra-vetted token is registered, that authorization starts returning a false response.

OpenConext / Stepup-Project

Allow self-vetting with self-asserted tokens #395