...

• 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 (are both meant here?) providers: Providers need not to 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. (overlap with the later "SP is responsible for asking for only what it needs...")
• 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? we go to lengths below with proxies!) is also a big advantage.
• The authorisation is decoupled from providing attributes.
• The service is responsible for asking for only what it needs and trusts to 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 mesh-like federation. 
• Explanation: we came up with tagging in eduGAIN so that we don’t break the trust model and yet , while entities can still express extra stuffadditional content.
  

Work Done

From Sprint Demo 4.6 - September 21/22:

...

Then, the user can prove the possession of such credentials without actually revealing them to a verifier organization. 

Use Cases (

...

Generalized)

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

...

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

...

Additional Source: https://irma.app/docs/revocation

Development

...

Work and

...

Demos

IRMA

...

Issuer Setup

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 handlers. The Javascript then requests the IRMA daemon using the result of the issuance session request and shows the result.

TODO figure

IRMA

...

Verifier Setup

The IRMA verifier is based on the simpleSAMLphp framework and implemented as an authsource. The authsource 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 handler and on receiving the successful disclosure response, the form is POST’ed 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 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

...