Definitions (

...

The text below is more an introduction on the DI and its significance/potential)

Distributed Identity refers to a particular method of verifying one’s identity and personal attributes to a relying party. 

...

The verification could use a digital infrastructure like digital signature verification on a signed piece of data or consultation with a registry or a distributed ledger. 

...

Motivation

There are several advantages to be gained from a Distributed Identity system in Research and Education (DI4R) setting:

• 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 entities can express extra stuff.
  

Work

...

Done

From Sprint Demo 4.6 - September 21/22:

• Implement and improve IRMA issuer in SimpleSAMLphp

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

• Investigate revocation

• Multi-valued attributes

Bellow are all (unclassified) features, achievements, findings, issues, todos and questions from Sprint Demo 4.6 - September 21/22 conclusions - keep in Done 3 or check against / move to 8, 2 or 411 (Future work):

• IRMA does improve end-user control over attributes

• Tracking behaviour is indeed impossible

• Is the app helpful or do we need to simplify GUI?

• Issuer chaining is still untested

• Per claim revocability (untested)

• No fallback for the mobile app at this time

• No central infrastructure collects all user data

• Not having a proxy reduces the administrative and legal burden
• Once claims are issued, the Issuer is no longer involved, this  improves scalability
• What is the legal/GDPR model, as ‘consent’ is not applicable
• Use of app adds to improved LoA
• LoA enhancing is much easier because of the mobile platform
• Service can cherry-pick claims; unused data is not send
• A distributed Identity model may provide a more flexible ecosystem, while it can still have similar trust properties as we have with eduGAIN
• Does an app provide us with better control over our ecosystem?

...

Functional

...

Model

Here provided comparative overviews illustrate the transition toward distributed identities.

Sourcing of

...

Claims

...

https://github.com/privacybydesign

Technical

...

Model

How does verification actually work in IRMA?

...

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 must display: the URL to itself and the session token.
4. The frontend (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 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, or 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.

Use of

...

Proxies

DI4R in Proxy Approach is a logical extension of the available data sources for a service, for which the multi-protocol proxy was created in the first place. 

...

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.

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

...

In order to overcome these challenges, an editorial system could issue certificates of for 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-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. 

...

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

Issues to

...

Address and Discussion 

Assurance

Since many sources can provide IRMA attributes, the IRMA platform does not standardise 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. 

...

This is a drawback as no independent channel is provided for the user's access to their information. The information is stored on the user device, defended by a PIN, which, should the mobile operating system get exposed, will also be compromised, and the private information can be stolen.

...