What is good UX for OOBI Exchange?

[edeykholt]

Related to setting up a multisig group. See #189

[nkongsuwan]

The default UX for peer-to-peer OOBI exchange between, say, Alice and Bob is:

1. Alice gives Bob her OOBI
2. Bob gives Alice his OOBI
3. Alice challenges Bob
4. Bob responds to Alice
5. Bob challenges Alice
6. Alice responds to Bob

This is a lot of steps in my opinion which is not good for UX. I think this process can be simplified for some specific use cases. For example, when a user requests an ACDC from a website (e.g. a government agency's website), perhaps this process could be simplified to:

1. The user clicks a button or scans a QR code on the agency's website.
2. The user admits the ACDC on their device.

Perhaps, OOBI resolution, challenges, responses, and IPEX Grants could be automated in between steps 1 and 2 here to provide better UX. This seems to be in the realm of credential exchange protocol, of which I do not have expertise.

[edeykholt]

Wanted to note the relevant KERI spec section: https://trustoverip.github.io/tswg-keri-specification/#out-of-band-introduction-oobi

[iFergal]

Some items of interest for me:

1. Similar to Nuttawut, how do we avoid needing to scan 2 QR codes to connect
2. How do we effectively tunnel communications and add "helper protocols" (like the Trust Spanning Protocol)
3. Dynamic ACDC schema resolution
4. Witness OOBI resolution

--

1. We could do something similar to a DIDComm connection but this is somewhat open to a man in the middle attack in case the AIDs don't have a human readable element or there is no pre-defined way ACDC to be presented after connecting. In the case of a website, the ACDC can easily be pre-defined, but this is harder for wallet to wallet connections.

2. In How do I establish and maintain a multisig group for one human? #188 I said that it might be useful if users have specific connection AIDs to tunnel communications, and with these connections we could run protocols that could help in setting up a multi-sig in a more automatic fashion for example. So that's what I mean by helper protocols. It can also help with privacy but maybe that's just a case that TSP is added.

3. In case an issuee of a credential is not aware of the ACDC being issued and disclosed to them via IPEX, I believe currently we cannot accept it. It would make sense to me if the discloser can stream the schema upon request (not by default, to avoid streaming unnecessarily) instead of requiring a wallet to go to a schema server. The problem with the schema server is a wallet that handles multiple ecosystems and use cases won't know which server to use.

4. Since watchers aren't implemented yet, a verifier will by default query the KERIA agent end role for KELs instead of the witness network. I'm curious when watchers are built how they become aware of new witnesses. In case an AID they watch had to spin up a new witness on a different domain, should there be an automatic way to discover new witness URLs from the existing witness set?

[nkongsuwan]

I think Phil working on the watcher capabilities. I also saw kli watcher recently updated as well here, though I haven't played with it yet.

[nkongsuwan]

The old IETF OOBI spec describes percolated discovery. Basically, witnesses and watchers share KELs that they observe with each other. I imagine someone could also implement OOBI routing mechanism through a network of witnesses and watchers in a similar manner to Kademlia/DHT.