Enables the flow API to handle WebAuthn/passkey logins with conditional mediation.
Implementation
Modifies the send_capabilities action by adding a new input for providing information about availability of conditional mediation on a client and stashing the value for further use.
Adds and applies a login flow hook that generates WebAuthn request options before the login_init state if conditional mediation is available (see point above) and applies the options to the response payload.
Applies the existing action for verifying a WebAuthn assertion to the login_init state. Because said action is now used on both mediated and un-mediated logins, it needs to know both the state the flow is in and the information about mediation availability in order to correctly suspend the action in the login_init state. Therefore I extended the InitalizationContext interface with a method to check whether the current state of a flow equals some other state. For this to work, the default implementation of the InitalizationContext had to be extended with a field to hold the FlowModel in order to have access to state information.
Tests
I have updated the generic_client in the backend/flow-api/static directory so you should be able to test this with it.
TODO
Because the send_capabilities check is used on all (non sub-)flows the mediation input is also present in flows where it is not relevant, i.e. registration and profile. Because Flows / FlowModels do not have any sort of "name" that generalizes over actual instances of a flow (which means: instances have IDs but I cannot use that in this scenario because they differ from instance to instance ...) there is no way to know what flow an action/hook is actually executed in during initialization of an action (or during execution/finalization for that matter ...). This means there is currently no clear cut way to determine that the conditional mediation input in the preflight state should be omitted on registration and profile flows.
Description
Enables the flow API to handle WebAuthn/passkey logins with conditional mediation.
Implementation
send_capabilitiesaction by adding a new input for providing information about availability of conditional mediation on a client and stashing the value for further use.login_initstate if conditional mediation is available (see point above) and applies the options to the response payload.login_initstate. Because said action is now used on both mediated and un-mediated logins, it needs to know both the state the flow is in and the information about mediation availability in order to correctly suspend the action in thelogin_initstate. Therefore I extended theInitalizationContextinterface with a method to check whether the current state of a flow equals some other state. For this to work, the default implementation of theInitalizationContexthad to be extended with a field to hold theFlowModelin order to have access to state information.Tests
I have updated the
generic_clientin thebackend/flow-api/staticdirectory so you should be able to test this with it.TODO
Because the
send_capabilitiescheck is used on all (non sub-)flows the mediation input is also present in flows where it is not relevant, i.e. registration and profile. BecauseFlows /FlowModels do not have any sort of "name" that generalizes over actual instances of a flow (which means: instances have IDs but I cannot use that in this scenario because they differ from instance to instance ...) there is no way to know what flow an action/hook is actually executed in during initialization of an action (or during execution/finalization for that matter ...). This means there is currently no clear cut way to determine that the conditional mediation input in the preflight state should be omitted on registration and profile flows.