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.

SAML-to-IRMA proxy provides the possibility of using a SAML federated account to get IRMA cards.

The next two figures illustrate the internal structure of a deployment.

Trust model

Also, compare the trust model to federation/eduGAIN.

IRMA key server is analogous to SAML Metadata as it provides the underlying certificates.

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?

https://irma.app/docs/overview/

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

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

With the introduction of DI4R, the flow may be significantly simplified. 

1. A creates a VO at the MMS service
2. A sends an invitation to B to the VO
   1. an email is sent to B from the MMS
   2. a card is registered to the registry?
3. B visits the link and receives the card, which is added to the wallet.
4. B visits a service that needs the entitlement and presents the card.
5. (the card is verified in the common registry, therefore revocation is possible

With this solution, B does not have to use the same login (i.e. the MMS and the target S do not need to be in the same federation). Possibly, B can receive the card at a page maintained by the DI4R provider. 

Or, perhaps the DI4R provider's web interface serves as a landing page for the invitation?

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.

• The "Single Blind" process is considered to be a minimum requirement - in this case, the author does not learn the identity of the reviewer. For most journals, this is considered insufficient, since the reviewers still know the identity of the author and they may be biased in one way or the other. Yet, in some cases, especially in less common language there is no true alternative as the content of the article drastically narrows down the set of possible authors, sometimes to one. In these cases the more anonymous methods are disingenuous.
• The "Double Blind" process means that neither the authors learn the identity of the reviewers or the reviewers of the authors. This is the most common type of peer review process. But it still leaves significant control in the hands of the editor, who knows the identity of both, plus, due to the structure of the fields of science, she may personally know all parties and have their own interest. The editor may also know the review styles of particular reviewers based on previous engagements. Therefore it is possible to pick a lenient or a strict reviewer for a given paper for instance.
• The Triple Blind method prevents this problem as the identities of the author, editor and reviewer are unknown to each other. However, this is the hardest to implements, as the editor still needs to be sure about the expertise of the reviewer, moreover, she should also know that the author does not temper with the process by being its own reviewer or bringing in friendly reviewers. At this point, the scientific process becomes somewhat analogous with e-voting systems.
• Furthermore, all three types of blind reviews have a common problem, which is that the work of the reviewer cannot be easily credited to them. This disincentivizes the reviewers from participating and therefore is a drawback for the entire scientific process.

In order to overcome these challenges, an editorial system could issue certificates of editing, certificates of reviewing and certificates of acceptance.

• The certificate of acceptance will contain the name of the author and the metadata of the article, therefore this can be handled as a simple card. 
• The certificate of editing will also contain the name of the author and the edited issue , making it very similar to the certificate of acceptance.
• The certificate of review should also be connected to the person who did the review but it should not reveal what the review entailed. The way for doing that is to be in a large-enough set of people so that the k-anonimity is sufficiently high. Otherwise, based on the exact timing and the fields of interest of a reviewer an author might be able to guess who did their review. Therefore, only larger time ranges (e.g. Year) should be revealed. Smaller journals may want to pool themselves together and issue a certificate that only says that the review was done in one in the journals in question. 

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.

1. User A (the sponsor already in collaboration)sends an email invitation to user B (outside the technical collaboration). 
   1. A describes B on a form at the VHO and inputs the email address of B
   2. the email is sent out.
2. User B visits the VHO service and receives a card that describes their identity as stated by A
   1. B visits the service, and reviews the data stated about her by A, and receives a card
   2. The card gets registered to the registry
3. User B can now access services within the collaboration.
   1. B attempts to access the service
   2. the service verifies the card in the registry and allows access.