...

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.

Functional model

Here provided comparative overviews illustrate the transition toward distributed identities.

Sourcing of claims

Use of proxies

The IRMA-to-SAML proxy allows for logging on to SAML SPs with IRMA cards.

...

Trust model

Also, compare the trust model to federation/eduGAIN.

...

The IRMA app is quite central, so the governance is a big difference (who puts what certificates to the app).

Technical model

How does verification actually work in IRMA?

...

Image from IRMA doc: https://irma.app/docs/what-is-irma/#irma-session-flow

Verifier: consume holder's credentials

Any entity that normally relies on an authentication flow that also aggregates attributes may use IRMA or another 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 accommodate the request if any. Alternatively, in this flow, the user may acquire new cards to fulfil the request. The wallet then sends the attributes to the service, which can verify them with a background call.

...

With this method, the Verifier no longer trusts an IdP (something that is exposed on the public internet) but trusts the authentication and the possession to the wallet. Arguably, this provides the opportunity to a stronger level of assurance (i.e. two factors to the wallet+possession of the device).

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 them 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 (is it how it is called, or 'IRMA card issuer protocol'?).

Issuer: attribute aggregation from Research AAI/MMS

In a traditional SAML flow, the following happens. The goal is to enable user Aladár (A) to manage the authorisation of user Béla (B) authorization to service S, but in a way that this information is not maintained in S but in an external source, the Membership Management Service (MMS). 

...

Issuer: Journal Use Cases

In the academic peer review process, honest opinions from an expert in the field are crucial. There is an inevitable tendency for specialization in science because any modern problems can only be tackled in focused, career-long efforts, so in most subdisciplines, the researchers will have a tendency of knowing each other. This, however, presents a challenge for the review process. In order to overcome the challenge, in the most widely used review processes, a degree of anonymity is introduced.

...

Virtual Home Organization

The Virtual Home Organization use case helps users wanting to access research & education infrastructure without having a home organization that is technically enabled with the accessed services on a technical level. While the technical integration is missing, the user may have a completely valid claim on access. In these cases a virtual home organization (VHO) is used. In this description we present the sponsored VHO use case, in which one user (within the technical collaboration) sponsors another (outside the collaboration) by an invitation.

...