Generalized transactions plan

[k8ieone]

Something like this could work:

/int/transaction - TBD, seems pretty complicated for now

type: onboarding
state: started | user info filled | finished
data: None

type: oidc_login
state: started | identified | code_issued | token_issued | finished/cancelled
data: Dict (mobile_transaction_id, OIDC data (Dict))

type: be_login
state: started | authorized
data: Dict (mobile_transaction_id)

GET /mobile/transaction?trx=UUID

state: started | identified | finished/cancelled -> removed
data: Dict (user_id - NOT RETURNED, app_name, extra_data (Dict))

/mobile/getTransactions - retrieves user's active transaction IDs, requires signed nonce

[k8ieone]

Different concept

Something like this could work:

/int/transaction

type: registration
state: started | user info filled | finished
data: empty
private_data: user info

type: oidc_login
state: started | identified | signed (code_issued) | token_issued | finished/cancelled
data: app_details
private_data: OIDC data

type: be_login
state: started | identified | signed
data: app_details, user

/authenticator

/authenticator/transactions - retrieves user's active transaction IDs, requires signed nonce

/authenticator/identify - moves a login transaction into the identified state

/authenticator/sign - moves a login transaction into the signed state

[k8ieone]

Okay, I'm probably done with this today...

Some closing thoughts:

• Transactions are modified by the respective flows (onboarding, login, etc.)
• The transaction endpoint will only serve as a way to check how a transaction is progressing
• I need to figure out a nice way to iterate through a user's transactions (can't easily iterate through Valkey keys since the number of transactions could be quite large)

[k8ieone]

Here are some brain-farts about user-configurable scenarios:

Each transaction is going to have a steps field. This field will be determined by YAML configuration.

e.g.

scenarios:
  - name: login
    steps:
      - identification: # steps for identification
        - or:
          - entry: # entry widget
              title: Email address
              fields: # The fields list is treated as an AND condition
                - email
          - entry: # second entry widget to allow either email or username
              tile: Username
              fields:
                - username
          - aqr:
              title: Anonymous QR
        - identify: {} # Use the gathered transaction data to identify an existing user
      - authorization:
        - device:
            title: Confirm on your authenticator device
            op: confirm

In this example the scenario is called login and allows the user to use either an AQR or to enter their username/email to identify themselves. The identify widget uses what the user has entered to bind the transaction to an existing user. If the user does not exist, the step fails. The next step is authorization which allows the user to use a device to confirm their login on an authenticator device.

For onboarding transactions something like this could work:

scenarios:
  - onboarding:
    steps:
      - details:
          - entry:
              title: Enter your registration details
              fields:
                - username
                - email
      - device-registration:
          - device:
              title: Add your first authenticator device
              op: register
      - registration:
          - write: {} # Save the gathered transaction data

Here the user is prompted for their details. Next they are asked to register an authenticator device and verify its public key. Finally the user is saved in the database along with all their gathered details. If the user's details were to collide with another existing user, this step fails.

What I'm worried about the most are the write and identify steps. The backend logic for those has to be pretty clever to allow for arbitrary use of these steps. E.g. changing the user's email address, adding another authenticator device, etc. What comes to mind is to store entered things in dicts that correspond to the database tables.

[k8ieone]

The transactions also need to have some kind of progress indicator.

We already have public and private data. With the addition of a steps JSON such as the structure mentioned above, I think we can store whatever the user enters on the FE in public data and BE stuff in private data. The steps JSON would also contain info about if the step was passed.

E.g.

[
  {
    "details": [
      {
        "entry": {
          "title": "Enter your registration details",
          "fields": [
            "username",
            "email"
          ],
          "state": "passed"
        }
      }
    ]
  }
]

In this example it would mean that the user has entered their registration details and we can assume that public data contains the username and email.

[k8ieone]

Well, that's all good for the far future. What I need to figure out is how to adopt Transactions now.

1. Using a valid onboarding link will create a new onboarding transaction
2. Entering the user details will add the data to the transaction
3. Registering the device will skip verification for now and just register the device (no changes here, just need to notify that the transaction is ready to move forward)

With onboarding the state flow will be created -> filled -> finished. Created will ask for filling, filled will ask for device activation, finished is the final state.