Skip to main content

User Registration

This chapter describes how a new User entity is created in the DEUSS Core platform. User registration stores the user's off-chain identity record, assigns the user to the correct broker tenant, and links the user to the credential type used by the onboarding channel.

The process can be initiated by an integrated Broker Partner System or by a DEUSS Backoffice Administrator.

Business Rules​

  1. Tenant assignment: In the partner flow, the user's broker relationship is derived from X-Partner-Id. In the admin flow, the target partner or broker is provided explicitly in the request payload.
  2. Partner authorization: Partner-created users require mTLS authentication and partner context injected by the API Gateway. The caller must have a role permitted to manage users, typically BROKER.
  3. Admin authorization: Admin-created users require an authenticated Backoffice session and a user-management role such as USER_MAINTAINER.
  4. Unique identity: The submitted email must not already belong to an existing user. For wallet-based creation, the wallet_address must also be unique.
  5. Credential consistency: A passkey-based user must include the required WebAuthn credential data. A wallet-based user must include a valid blockchain wallet address and leaves passkey fields empty.
  6. Auditability: Every user creation attempt is recorded in audit logs with the caller identity and context.

Business Flow​

  1. Registration Initiation:

    • The partner or admin initiates user creation through the Registry Service.
    • The request includes the user's profile data and the credential data required by the selected onboarding mode.
    • The partner-facing flow creates the user inside the caller's tenant. The admin flow can create a user globally and assign them to the correct broker or partner.

  2. Credential Selection:

    • In the passkey-based flow, the user is associated with WebAuthn data, including the passkey ID and public key. This supports the platform's passwordless authentication model.
    • In the wallet-based flow, the user is provisioned with a trusted wallet_address as their primary credential identifier, typically for authentication based on cryptographic message signing.
    • Wallet-based creation is purely off-chain. It stores relational access data and does not trigger smart contract operations.

  3. Validation and Persistence:

    • The Registry Service validates authorization, tenant context, required fields, email format, and credential format.
    • It then checks uniqueness constraints for the user's email and, when applicable, wallet address.
    • If validation succeeds, the user record is stored in the Core database together with the selected credential information.
    • The API returns the created User entity to the caller. In admin-driven flows, the response may also support manual distribution of invitation or onboarding information.

  4. Failure Handling:

    • Missing or invalid credentials lead to an unauthorized response.
    • A caller without the required user-management role is rejected as forbidden.
    • Missing passkey data, missing wallet address, invalid email format, invalid wallet format, or missing tenant assignment in the admin flow is treated as a bad request.
    • Duplicate email or wallet data is rejected as a conflict.

Sequence Diagram​