Basic use cases in DIDroom

[andrea-dintino]

This is a brainstorming for the basica use cases we COULD implement in DIDroom. Those are to be implemented in templates but executed by the microservices. We'd go from the easier to the most complex, and it could make sense to brainstorm further.

• voucher model: a microservice generates some 1000 random tokens, and presents one token per time (via GUI or via API). The token is entered manually by the user in the authorization flow.
  • Verification: the vouchers have to be single-use, so the relying party has to: verify the signature, call an api to verify that the voucher is valid, passing a parameter that asks to delete the voucher from the database.
• Proof of DID: this is basically the flow we already have, the user's DID is proved via PoP/DPoP, and the issuer inserts the DID (or part of the DID) in the credential. Inserting the whole DID would go against anonymity and unlinkability but insertng just did:dyne:domain.context could be interesting as it would prove some sort belonging to a certain community
• Proof of humanity: a realistic proof of humanity can be done by insterting a simil-captcha in the auth page, something like "what is the sum of 13 and 24?"
• Proof of registered email v1: this can be achieved in several ways. One way is via a token sent per email using the voucher above. Note: this defeats the anonymity and unlinkability, but there are ways around, for example for an email such as andrea@organization.org, the issuer will use 2 claims, like:
  {"email": "andrea@organization.org",
  "email_obfuscated": "a...a@organization.org"
  }

We could create use cases that rotates around the features offered by pocket base, so basically the POST done to the auth_server and credential_issuer are done to pockebase APIs, e.g.:

• Membership and roles in an organization:

  • Auth: the auth_server asks pocketbase if a certain DID (or email) is a member of a certain organization
  • Credential (membership expiry): There will be multiple issuance flow for multiple durations of the membership, e.g. "perpetual" or "one year". Based on that, the credential_issuer will calculate the expiry date
  • Credential (membership role): there are also several different roles in the organization, and a credential could be issued based on that too. In this case, the issuer will insert the role in the credential as a claim and sign it
  • Verification: a verification flow has to be created, per organization and/or per role. The relying party will verify the signature and then will verify that the organization/role matches the one in the verification template

• Proof of registered email v2:

  • auth: the auth server only needs the DID of the user, it will just check the existence on pockebase
  • issuer: once received the token with user's DID, the issuer will query the same pockebase API from above, retrieve the email and insert it in the credential as a claim. See note above for the anonymity issue.
  • Verification: here the relying party simply verifies the signature