Definitions

...

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

...

• 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?)service  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, while entities can still express additional content.
  

...

• 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 3 or check against / move to 8, 2 or 10 (Future work); some items need extra elaboration:

• Expressing assurance from source

• Investigate revocation

• Multi-valued attributes

• IRMA does improve end-user control over attributes [BMa: already mentioned]
  

• Tracking behaviour is indeed impossible [already mentioned]

• Is the app helpful or do we need to simplify GUI? [kinda already mentioned in 10 but not as simplification - "Enhanced presentation of cards"]
  

• Issuer chaining is still untested

• Per claim revocability (untested) [already mentioned]

• No fallback for the mobile app at this time

• No central infrastructure collects all user data [already mentioned]

• Not having a proxy reduces the administrative and legal burden [already mentioned]
• Once claims are issued, the Issuer is no longer involved, this  improves scalability [kinda already mentioned]
  
• 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 (and user!) can cherry-pick claims; unused data is not sent [already mentioned]
  
• A distributed Identity model may provide a more flexible ecosystem, while it can still have similar trust properties as we have with eduGAIN [already mentioned]
  
• Does an app provide us with better control over our ecosystem?

Functional Model

Here provided comparative overviews illustrate the transition toward distributed identities.

...

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

...