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.

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 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.

Issuer: SAML attributes into IRMA tokens

An obvious source of "cards" is a SAML federation. In order for a SAML attribute of a user to be converted to a card, the user needs to visit an entity that acts as a proxy. This proxy needs to behave as a SAML SP towards the user and the SAML federation. The user needs to visit the site with the intent of adding a card to their IRMA app so that the IRMA infrastructure can store the data as a card. The user will be logged in to this SAML SP which will consume the attributes from an IdP / AA then store it to the IRMA infrastructure.

Issuer: 'native' triple stack IdP issuing SAML, OIDC and IRMA

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.

Issuer: attribute aggregation from Research AAI/MMS

A membership managements system stores role and group information.
These may be released as cards. Here, TTL/revokation plays an especially important role.