Skip to Content
User FlowsGroup credentials

Group credentials

Group identifiers can also hold and manage credentials! In KERI, this would also be a common flow because credentials can be chained together to form a chain of trust.

For example, a company might issue a department a credential, which in turn allows it to issue credentials to people in their department. The department is controlled by a group of department heads, so in the end, we will have a cryptographic chain between Company -> Department -> Employee.

Connections

Connections work almost the same way as before! Using the issuer tool as an example again — every group member will need to scan the QR code of the issuer tool using their wallet.

However, only one group member needs to share the group QR code (from the identifier details share screen) with the issuer tool. This is because the QR code is set up to ensure that the other party knows of all group members when connecting.

Note that the name that appears in the issuer tool connection list will be the wallet name of the member who shared the QR code. We’re working on improving this.

It’s also on our roadmap for members to share connections back and forth, so a group member can introduce another wallet or service to the other group members.

Notifications

Now, whenever a connection is interacting with you, each group member should receive a notification. In case a group member doesn’t receive one, or the connection name is Unknown, it means that they forgot to scan the issuer’s QR code within their wallet.

Group leaders

Since we’re working in an environment that doesn’t have a centralized component, it becomes more difficult to handle concurrency. The associated challenges are discussed here in the community, and we’d like to leverage a designated KERIA server within each group to improve on that in the future.

As such, it’s important for there to be a group leader who proposes to the group what action the group should take, and other members can accept or reject the proposal. In our wallet, the group leader is the group initiator — the person who originally decided to set up the group.

The ability to update the group leader is on our roadmap.

Receiving a credential

In the context of credential issuance this means once the notification is received, only the group initiator will be able to act on it. Afterwards, the other members can also accept it.

It will be complete once a threshold number accept it. Any other group members outside of the threshold can also add it to their wallet later too by accepting the notification.

Presenting a credential

The same applies for presenting a credential — only the group leader gets to choose what credential to propose, and others can accept or reject. To accept the proposal, you need to ensure you still hold the credential. If you don’t, you will see this feedback in the UI — this can happen in two cases:

  • You have not accepted the credential yet, but the group as a whole have and the threshold was met.
  • You accepted the credential but later deleted it from your wallet. If you archived it, you will still be able to join.
⚠️

For now, rejection simply means ignoring the request. So if the threshold cannot be met, the flow should be started over with a new presentation request from the verifier.

We’ll add the ability to restart flows and propose something else later — for now it doesn’t add enough value since in reality a group likely might only have 1 matching credential for a request.

Revocation

There is no change for revocation! Each member will receive a notification, and the status of the credential will automatically update in their wallet.

Last updated on