New Client Flow

[xilosada]

Currently, the client flow for identity management is integrated into the core repository, resulting in a login flow that is too tightly coupled with the node. To enhance user experience and maintain a clean codebase, we propose the following changes:

1. Extract Client Flow:

   • Separate the client flow from the core repository.
   • Allow webapps (or native/mobile apps) to work with a context identity without requiring the admin.
   • Enable the creation of apps with the node embedded.

2. Token Request or Pubkey Registration:

   • Enable webapps to request a token or register a public key with permissions to interact on behalf of the user.
   • This will streamline interactions and improve flexibility.
   • Permissions to include:
     • List contexts related to an appId.
     • Join a contextId (allowing the user to choose to create a new context identity or use an existing one).
     • Join with callable methods, enabling permissions to call specific methods within the app.
     • Call app methods.
     • Allow methods of the same appId to be called for multiple contexts.

3. Independent Key Management:

   • Ensure key management is independent of the SDK.
   • Abstract the flow so that webapps do not delegate any payload signing process, maintaining security and separation of concerns.
   • Allow unsafe nodes, nodes that don't have any root key registered.

Benefits:

• Enhanced user experience with a more flexible and decoupled login flow.
• Improved security through independent key management and abstracted signing processes.
• Granular permissions management for better control and security.

Acceptance Criteria:

• The client flow is successfully extracted and operates independently.
• Webapps can request tokens or register pubkeys using the SDK.
• User clearly understand the payload content before sending it to the node. The permissions requested have clear explanations
• Key management is fully independent and abstracted with the SDK. The node can work without root keys.
• Permissions management is implemented, allowing for listing contexts, joining contexts, and calling app methods. Requesting permissions for specific functions will be discussed separately.

Flow Diagram:

sequenceDiagram
    participant Webapp
    participant Admin-UI
    participant Node
    participant Webwallet

    Webapp->>Admin-UI: join(contextId)
    Admin-UI->>User: Request permissions
    User-->>Admin-UI: Accept permissions
    Admin-UI->>Node: Fetch list of contextIds
    Node-->>Admin-UI: Return list of contextIds
    User->>Admin-UI: Selects or creates context
    Admin-UI->>Admin-UI: Generate payload
    Admin-UI->>Webwallet: Request signature
    Webwallet-->>Admin-UI: Return signed payload
    Admin-UI->>Node: registerApp(signed payload)
    Node-->>Admin-UI: Confirmation
    Admin-UI-->>Webapp: Confirmation

sequenceDiagram
    participant Webapp
    participant Admin-UI
    participant Node

    Webapp->>Admin-UI: join(contextId)
    Admin-UI->>User: Request permissions
    User-->>Admin-UI: Accept permissions
    Admin-UI->>Node: Fetch list of contextIds
    Node-->>Admin-UI: Return list of contextIds
    User->>Admin-UI: Selects or creates context
    Admin-UI->>Admin-UI: Generate payload
    Admin-UI->>Node: registerApp(payload)
    Node-->>Admin-UI: Confirmation
    Admin-UI-->>Webapp: Confirmation

[MatejVukosav]

Few quick comments after quick look.

• user is usually first thing in diagrams from which all starts
• "Allow webapps (or native/mobile apps) to work with a context identity without requiring the admin." <-> then on diagram there is dependency to admin dashboard.
• I don't think that app should talk to admin dashboard directly. Both of them should write/read data from admin server so we don't depend on dashboard

[xilosada]

I don't think that app should talk to admin dashboard directly. Both of them should write/read data from admin server so we don't depend on dashboard

@MatejVukosav then the user has to trust that the webapp is not tinkering a different payload for a different app or context

"Allow webapps (or native/mobile apps) to work with a context identity without requiring the admin." <-> then on diagram there is dependency to admin dashboard.

They create their own node config and don't use admin at all

[frdomovic]

Allow methods of the same appId to be called for multiple contexts. @xilosada whats the purpose of this? Example?

[xilosada]

Allow methods of the same appId to be called for multiple contexts. @xilosada whats the purpose of this? Example?

Multicontext. Applications like chats which use different contexts per chat room

[miraclx]

I don't think that app should talk to admin dashboard directly. Both of them should write/read data from admin server so we don't depend on dashboard

I think the idea is to introduce indirection, like WalletConnect. With our Admin UI being one of the options, and could be expanded to include extensions, Yubikey, Ledger, Passkeys (so you can scan a QR code on your phone), fingerprint, raw seed phrase input.. whatever at their convenience

But in the signing flow, we present a breakdown of the requested permissions to the user, so they know exactly what they are signing.

From the apps pov, it's a unified interface so they don't have to care which method the user wants to use to sign the transaction.

And the users feel secure too because they know they aren't signing arbitrary payloads.

I can get behind this.

user is usually first thing in diagrams from which all starts

agree, would certainly simplify things

[MatejVukosav]

Duplicated https://github.com/calimero-network/core/issues/569