setup UI endpoint to serve the UI

[llorllale]

setup UI endpoint to serve the UI

[talwinder50]

As per the discussion the plan team agreed upon is.

User agent on page load will be redirected to Hub-Auth. After successful login, there will be did communication to share the bootstrap data.

• Hub-Auth need to have public DID
• Hub-Auth will generate invitation
• Hub-Auth will send the invitation to user-agent via redirect URI
• Then DID Comm connection will begin using messaging protocol.

[llorllale]

@talwinder50 @sudeshrshetty @DRK3

Based on today's call:

Draft of flow

[sudeshrshetty]

@llorllale @talwinder50
You don't have to call CHAPI to send user bootstrap info. Remember, CHAPI registration happens after successful login.
Webwallet registration already has api to save user metadata (refer wallet-metadata store in jsindexdb).
Currently, we are saving username, user DID, invitation & signature type. You just have to add more fields in already existing wallet user metadata.

https://github.com/trustbloc/edge-agent/blob/master/cmd/user-agent/src/pages/chapi/Login.vue#L83

[llorllale]

@sudeshrshetty @talwinder50 we need to talk about this then because this flow will change anyhow.

In the long run: hub-auth and edge-agent should exchange key material (DIDs) to create a secure authenticated channel. hub-auth can push updates through this channel, and offer services the user may also use

In the short run: edge-agent should register key material (DID) in hub-auth. With this, the user does not have to be redirected to hub-auth whenever they need to authenticate to other components (eg. adapters)

[llorllale]

@sudeshrshetty @talwinder50 @aholovko as we discussed, here's my proposal in rough form. Please weigh in to see if it looks like it's going in the right direction:

---

Proposal: hub-auth sends bootstrap data to the wallet via CHAPI

Goals:

• Authenticate the user using an external OIDC provider
• User SSO
• Adapters (and other components?) do not redirect the user (again) during the login phase

Assumptions:

• User will be authenticating to the adapters much more frequently than to hub-auth
• The wallet is already registered as a CHAPI Credential Handler in the user's browser

Flow (1st time login):

1. User navigates to wallet domain and clicks on Login
2. Redirect to hub-auth
3. hub-auth redirects to OIDC provider
4. OIDC provider authenticates user
5. User redirected back to hub-auth
6. hub-auth onboards user in network
7. hub-auth sets up bootstrap data
8. hub-auth creates a CHAPI request with bootstrap data
9. hub-auth invokes navigator.credentials.get({bootstrap data})
10. edge-agent stores bootstrap data
11. edge-agent creates new key pair (did:key?)
12. edge-agent responds (CHAPI) with pub key
13. hub-auth verifies everything is OK
14. (Optional) redirect user back to wallet domain

Key features:

• Wallet registers a key with hub-auth, which means the user doesn't need to be redirected anywhere when authenticating to the Adapters

[llorllale]

@Baha-sk @DRK3 ^^ @aholovko

[sudeshrshetty]

@llorllale here are the points I am concerned with.

• we shouldn't register CHAPI before login. It will initialize polyfill handler in browser and user can launch CHAPI window without login (even after failed login). In current basic implementation we have, polyfill handler gets registered/unregistered during login/logout, I propose we should stick to that.
• hub auth request with bootstrap data should be generic, we shouldn't send bootstrap data through CHAPI (also, we can't send CHAPI request if wallet is not registered).
  We have 'webwallet JS API' in place to handle user registration/login, we can resuse/modify that to handle user bootstrap data without involving CHAPI.
  Reasons:
  • CHAPI is just an iframe handler by polyfill handler JS API, it is as secured as user agent login page.
  • CHAPI request (store call in your case), should have data only in presentation format (means, CHAPI request for store() should only be in presentation format). We shouldn't send arbitrary data to CHAPI.
  • CHAPI when launched transits to thirdparty domain even if they are local (like authn.io, which may not be safe for sensitive data like user bootstrap data)
• Bad User Experience: for simple login we have to go through 3 popups/pages
  • wallet registration popup
  • login page
  • wallet selection popup + showing some UI for bootstrap data in CHAPI window + accept it

@troyronda @rolsonquadras @fqutishat ^^