...

• Better attribute aggregation: in a DI4R setting, attribute aggregation happens within the user wallet. This enables attributes from more sources with the user in perfect control of the release.
• Easier integration for the identity and service providers: Providers need not federate - they can decide to provide or consume user information or stop doing that at any time and it is only up to the user whether they want to provide attributes or not. 
• No tracking by IdP: In a SAML or OIDC setting, the Identity Provider can track in real-time where its users are logging in. In DI4R, the issuer cannot track any subsequent usage of the issued information and thus learn about the user's behaviour.
• Easier compliance with GDPR:
• The user holds control over cards and can easily delete them.
• For the IdP there is not much difference, except in terms of less control - the IdP cannot know/limit what happens with the credentials once issued - they can only track their inclusion into the user's wallet (including after a claim has expired or is revoked)
  
• The IdP's ability to control attribute release improves privacy and data protection.
• Not having a proxy (in the long run -proxies are temporarily very useful) is also a big advantage.
• The authorisation authorization is decoupled from providing attributes.
• The service is responsible for asking for only what it needs and whom it trusts and is responsible for claims regarding verification, authorization and GDPR-complied handling of released information.
• Easier in the ecosystem to exchange information without top-level trust route approval - basically a mesh-like federation. 
• Explanation: we came up with tagging in eduGAIN so that we don’t break the trust model, while entities can still express additional content.
  

...

• Implement and improve IRMA issuer in SimpleSAMLphpsimpleSAMLphp

• Test verification of claims from multiple schemes

• Explore the best way to describe the scheme

• Discuss IRMA ‘metadata’ distribution risks

• Investigate assurance

• Device assurance

• Expressing assurance from the source

• Investigate revocation

• Multi-valued attributes

...

Since the components of that system are available on GitHub, and several key components are already Licenced Licensed with Apache 2.0, it is natural that we opted to experiment with that. 

...

Technical Model

How does verification actually work in IRMA?

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

Source: IRMA documentation: https://irma.app/docs/what-is-irma/#irma-session-flow

Software components [https://irma.app/docs/overview/]:

• Requestor backend and frontendback-end and front-end: Generally the requestor runs a website with a (JavaScript) frontend front-end in the user's browser and a backend back-end server. During an IRMA session, the front end displays the IRMA QR that the IRMA app scans. All frontend front-end tasks depicted in the diagram are supported by irma-frontend.
• IRMA server: Handles IRMA protocol with the IRMA app for the requestor.
• IRMA mobile app: Android, iOS.

...

1. Usually, the session starts with the user performing some action on the website (e.g. clicking on "Log in with IRMA").
2. The requestor sends its session request (containing the attributes to be disclosed or issued, or message to be signed) to the IRMA server. Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed session request JWT) from an authorized requestor.
3. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend front-end must display: the URL to itself and the session token.
4. The frontend front-end (irma-frontend) receives and displays the QR code, which is scanned by the IRMA app.
5. The IRMA app requests the session request from step 1, receiving the attributes to be disclosed or issued, or the message to be signed.
6. The IRMA server returns the session request.
7. The IRMA app displays the attributes to be disclosed or issued, or the message to be signed, and asks the user if she wants to proceed.
8. The user accepts.
9. The IRMA server performs the IRMA protocol with the IRMA app, issuing new attributes to the user, receiving and verifying attributes from the user's IRMA app, or receiving and verifying an attribute-based signature made by the user's app.
10. The session status (DONE, CANCELLED, TIMEOUT), along with disclosed and verified attributes or signatures depending on the session type, are returned to the requestor.

...

In the academic peer review process, honest opinions from an expert in the field are crucial.  There 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 subdisciplinessub-disciplines, the researchers will have a tendency of knowing tend to know each other.  ThisThis, 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 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-anonymity 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, a year range) 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 of the journals in question. 

...

Since many sources can provide IRMA attributes, the IRMA platform does not standardise standardize levels of assurance beyond individual profiles. Assurance levels are provided by using the corresponding schema-defined credential attributes, that is, IRMA passes on the level of assurance provided by sources only if these levels are incorporated into the used schema and implemented by the IRMA issuer. 

For example, the attribute “assurancelevel” is used in schemas that provide data from passports or ID cards, and it conveys the levels set by the document issuer or an intermediate entity that collected and verified the information provided with the credential. This level is in line with eIDAS. Some other schemes use “digidlevel” to provide the level from the Duch Dutch Digital ID (digid.nl), which is the assurance with which identity is verified in the Dutch population register.

...

However, IRMA is a mobile-only application, and, obviously, no user will so the user is less likely to have a second mobile device that may act as an independent source of authentication. 

...

At the same time, many factors alleviate this concern. For one, mobile operating systems, while not invulnerable, are much less exposed to malware according to statistics (TODO REF), probably due to their platforms with walled gardens are more controlled software/package management are likely to be less exposed to malware. This of course deteriorates once the operating system is no longer supported.

...

One such challenge is the QR-Code reading for which the smartphone is especially well suited, but is not impossible in another architecture either, i.e. a browser extension. Another challenge is the safe storage of the ‘cards’, but that also can be done

Schema and Multi-Valued Attributes

TODO

Attribute Revocation

Revocation is enabled per credential type in the IRMA scheme. If so, the properly configured issuer’s IRMA  will issue revocation-enabled credentials of that type. If the user has a revocation-enabled credential then proving non-revocation is not required; instead, they can just disclose attributes from the credential, which is much cheaper. Non-revocation is still ensured by using revocation update messages which are created whenever an issuer performs a revocation, which also distributes issuer-related information that is updated at the time of revocation and is necessary to disclose attributes.

...

IRMA issuer consists of a small PHP server that relies on simpleSAMLphp for authentication. In the case of success, this call results in a populated attributes array that is then fed into the IRM IRMA daemon session request API for an issuance session and the result is handed over to the JavaScript handlers. The Javascript JavaScript then requests the IRMA daemon using the result of the issuance session request and shows the result.

...

The IRMA verifier is based on the simpleSAMLphp framework and implemented as an "authsource". It shows a web form and creates a disclosure session request using the IRMA daemon API. The result of this request is then handed over to the Javascript JavaScript handler and on receiving the successful disclosure response, the form is POSTed back to the simpleSAMLphp authIRMA handler and further processed as a valid authentication.

...

• Multi-valued attributes
• Alternative wallets
• Scalable schema definition for a size of a federation like eduGAIN (of issuers)
• 5k or more entities
• Peer-to-peer claims (cards)
• Pixie dusting - claiming that someone is your co-worker, club member, etc. 
• Conventions on prefixes for wildcards used on attribute names
• Use of multiple schemas and schema selector
• UX is not hard but needs to be done well
• allows for different universes of DI4R
• Enhanced presentation of cards
  • Since the user is in charge of exposing cards in their wallet to the service, it is important to present these cards, their content and their source in a clear but informative way. This requires further establishing of a standardised standardized and scalable way to specify their presentation and access to supporting information which is also interoperable with existing identity infrastructures and trust frameworks.
• Usability testing/evaluation
• DI4R is a new concept, so it is a reasonable question whether the users understand the flow at all and the benefits that justify the adoption of changes. Should be done with appropriate early adopters such as researchers involved in Open Science.

Leftover Diagrams and Material

...