...

• 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 provider: Providers need not to federate - they can decide to consume or stop consuming user information 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.
• Easier compliance with GDPR:
• The user holds control over cards and can easily delete them.
• For the IdP there is not much difference (actually can be less good, less control - the IdP cannot know/limit what happens with the credentials once issued.
• Not having a proxy! is a big advantage with regards to the GDPR.
• SP is responsible for asking for only what it needs, and in an IRMA-like system you always get what you ask for.
• Easier in the ecosystem to exchange information without top-level trust route approval - basically mesh-like federation. 
• explanationExplanation: we came up with tagging in eduGAIN so that we don’t break the trust model and yet entities can express extra stuff.

Functional model

Here provided comparative overviews illustrate the transition toward distributed identities.

...

The source code of the system is available hereat:

https://github.com/privacybydesign

...

The following use case descriptions present some ideas of how the system may be used in an academic setting.

Issuer: SAML attributes into IRMA tokens

...

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

...

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

...

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 of the wallet. Arguably, this provides the opportunity to for a stronger level of assurance (i.e. two factors to the wallet+possession of the device).

...

Login names and passwords may fall prey for to a hacked browser or operating system, in which case an independent channel - a one-time password challenge, a push notification on a secondary device, paper-based factors or even something as weak as an interceptable SMS can provide a crucial last line of defensedefence. 

Most of the currently trending second-factor options assume the primary channel to be a desktop or laptop computer and the mobile as a secondary device. 

...

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 daemon session request API for an issuance session and the result is handed over to the Javascript JavaScript handlers. The Javascript then requests the IRMA daemon using the result of the issuance session request and shows the result.

...

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

...