Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Loggi

This document summarizes the various use cases of DI4R. The use cases are categorized by role: whether an entity is a consumer or a producer of attributes.

Functional model

Branco to add first model here based on stuff fro chapter 8

Here provided comparative overviews illustrate the transition toward distributed identities.

Sourcing of claims

Please review the yellow notes with doubts...

Gliffy Diagram
size850
displayNameSourcing
nameSourcing
pagePin10

...

The IRMA-to-SAML proxy allows for logging in on to SAML SP-s SPs with an IRMA cardcards.

Gliffy Diagram
macroId1fde878d-88d5-4d69-af6b-ecb01aab2176
displayNameIRMA-to-SAML proxy
nameIRMA-to-SAML proxy
pagePin14


SAML-to-IRMA proxy provides with the possibility of using a SAML federated account to get IRMA cards.

macroId
Gliffy Diagram
77e857c5-51a2-450e-902c-a56728b7f329nameSAML-to-IRMA2
pagePin12

The next two figures how illustrate the internal structure of a deployment.

Gliffy Diagram
macroId42c871d4-d0df-4165-8065-e91d635ca869
displayNameProxy structure
nameProxy structure
pagePin12

Add Social to 4.2? - Where exactly?

Proxy proliferation → Proxy chaining?

Place Gipsz beneath the left claim in DIR4R, for which you could add a note "Holder tries to anonymously admin the service".

Use a simple non-serif in grey notes. Enlarge small yellow notes.

Trust model

also Also, compare the trust model to federation/eduGAIN.

IRMA key server is analogous to SAML Metadata as it provides the underlying certificates.

the The IRMA app is quite central, so the governance is a big difference (who puts what certificates to the app).

Technical model

How does verification actually work in IRMA?

...

Image from IRMA doc: https://irma.app/docs/what-is-irma/#irma-session-flow

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.

Gliffy Diagram
macroIda2169e2a-99ff-4bc2-8bde-b3625d5a3715
displayNameVerifier
nameVerifier
pagePin2

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

...

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 it them to the IRMA infrastructure.

Gliffy Diagram
macroId7ff33578-1faf-4ed1-ae22-5416a3a5ae07
displayNameSAML-to-IRMA
nameSAML-to-IRMA
pagePin23

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 IssuerCard Issuer (is it how it is called, or 'IRMA card issuer protocol'?).

Gliffy Diagram
macroIde833a0bd-273f-48b8-87a2-037031d96236
displayNamemulti-protocol
namemulti-protocol
pagePin14

Issuer: attribute aggregation from Research AAI/MMS

...

Issuer: Journal Use Cases

An an In the academic peer review process, honest opinions from an expert of in the field is are crucial.

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 subdisciplines the researchers will have a tendency of knowing each other.

This, 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 "Single Blind" process is considered to be a minimum requirement - in this case, the author does not learn the identity of the reviewer. For most journals, this is considered insufficient, since the reviewers still know the identity of the author and they may be biased in one way or the other. Yet, in some cases, especially in less common language there is no true alternative as the content of the article drastically narrows down the set of possible authors, sometimes to one. In these cases the more anonymous methods are disingenuous.

...

Furthermore, all three types of blind reviews have a common problem, which is that the work of the reviewer cannot be easily credited to them. This disincentivizes the reviewers form from participating and therefore is a drawback for the the entire scientific process.

Gliffy Diagram
macroId185be960-9022-4171-bab6-ace1919b0ce9
displayNameJournal to IRMA
nameJournal to IRMA
pagePin14

Revocation

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

...