Clarification regarding multisig OOBI

[lenkan]

There has been some discussion on github and discord regarding how multisig OOBI urls work. This issue on signify-ts contains some further references: https://github.com/WebOfTrust/signify-ts/issues/193

Consider a group AID multisig with participants member1 and member2 and their keria agents agent1 and agent2. Currently, when calling GET /oobis/multisig to generate an OOBI url for the group, you have to specify the role as either agent, witness or controller.

So, for example, if member1 would call this endpoint to generate an OOBI url for the group they would specify the role parameter agent and and get a result:

https://keria-url/oobi/<multisig aid>/agent/<agent1 aid>

If another AID, for example a credential issuer resolves this OOBI url and then grants a credential to that AID, only member1 would receive this message.

The current workaround is to construct an URL on the client side by stripping the /agent/<agent1 aid> part of the URL. So you would get:

https://keria-url/oobi/<multisig aid>

See the example scripts in signifypy and signify-ts:

• https://github.com/WebOfTrust/signifypy/blob/e15129147c40faf587485e7cd46f8f179672d22b/scripts/multisig-holder.py#L113
• https://github.com/WebOfTrust/signify-ts/blob/5be18192520f63eba83011379049f42e83b02ee0/examples/integration-scripts/multisig-holder.test.ts#L396

[2byrds]

From our dev meeting: Only one oobi is being chosen in the signify-ts example. There are a number of options:

1. Clients can review the agent OOBIs and return the non-role OOBI (like seen in the tests). Does this belong in the logic or API? If this is handled at the API level it would help the user to receive the generic OOBI. @Arsh-Sandhu will send his fix.
2. Generate an OOBI url with just a role in it
3. Consumer can resolve all oobis

[lenkan]

Here is a reference to a discussion in discord regarding this: https://discord.com/channels/1148629222647148624/1148734044545228831/1194270946215854182

[2byrds]

See https://github.com/WebOfTrust/keria/issues/305 and once this is resolved this process will be documented/clear.