This document summarizes the various use cases of DI4R. The use cases are categorized by role: whether an entity is a consumer or a producer of attributes.

Trust model

Technical model

How does verification actually work in IRMA?

Verifier: consume credentials from holder

Any entity that normally relies on an authentication flow that also aggregates attributes may use IRMA or other service for login. In this process, the user is challenged with a QR Code to brandish attributes with the help of the wallet app. The wallet app reads the QR code and engages in user interaction: it shows what is requested by the service and which "cards" - previously stored attributes accomodate accommodate the request, if any. Alternatively, in this flow the user may acquire new cards to fulfill the request. The wallet then sends the attributes to the service, which can verify them with an background call.

...

An authentication source may already have to support multiple protocols, (for instance, SAML and OIDC) in order to cater for the modern web environment. A logical extension of this idea is to support an additional protocol, the card Issuer.

...

1. A logs in on the web interface of the MMS, a SAML SP and an account is created.
2. A creates a Virtual Organization / Community / Group - terminology depends on the actual tool but let's call it (VO)
3. A wants to invite B to his VO. In order to do this, he needs an email address to B. This email address serves as a trust anchor for the moment, therefore it needs to really belong to B and not be compromised.
4. A sends an email invitation to B with a link containing a token. The email is sent by the MMS system.
5. B follows the link to the web interface of the MMS, prompted for login. B may already have a login (for previous participation in other VOs) or needs to create a new one. B may log in with a federate account but it could be the case that there is none, and a local account is created or a VHO account is used. This scenario is made possible by the fact that really the access to the email inbox is what provides the trust for the VO membership.
6. After creating/accessing a local account, the token sent in the link is processed and B's account is now associated with the VO. 
7. B will eventually access a service that needs this membership information, commonly called entitlement.
   1. The service will perform a login flow
   2. with B's user identifier queries the MMS backendback-end, for instance a SAML AA or an integration. This requires the usage of the same user identifier that was used at the MMS, typically a common OIDC/SAML source.
8. A may revoke the entitlement at any time, which will take effect at the next session: the service accessed will query the MMS and will not get the entitlement.

...

Revocation

Issuer action

User action

...