...
- Usually, the session starts with the user performing some action on the website (e.g. clicking on "Log in with IRMA").
- 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 authorised requestor.
- 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 front-end must display: the URL to itself and the session token.
- The front-end (irma-frontend) receives and displays the QR code, which is scanned by the IRMA app.
- The IRMA app requests the session request from step 1, receiving the attributes to be disclosed or issued, or the message to be signed.
- The IRMA server returns the session request.
- 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.
- The user accepts.
- The IRMA server performs the IRMA protocol with the IRMA app, issuing new attributes to the user, receiving and verifying attributes from the user's IRMA app, or receiving and verifying an attribute-based signature made by the user's app.
- The session status (DONE, CANCELLED, TIMEOUT), along with disclosed and verified attributes or signatures depending on the session type, are returned to the requestor.
...
Then, the user can prove the possession of such credentials without actually revealing them to a verifier organization.
Use Cases (
...
Generalised)
The following use case descriptions present some ideas of how the system may be used in an academic setting.
...
- 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 languages 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.
- The "Double Blind" process means that neither the authors learn the identity of the reviewers nor the reviewers of the authors. This is the most common type of peer review process. But it still leaves significant control in the hands of the editor, who knows the identity of both, plus, due to the structure of the fields of science, she may personally know all parties and have their own interest. The editor may also know the review styles of particular reviewers based on previous engagements. Therefore it is possible to pick a lenient or a strict reviewer for a given paper for instance.
- The Triple Blind method prevents this problem as the identities of the author, editor and reviewer are unknown to each other. However, this is the hardest to implement, as the editor still needs to be sure about the expertise of the reviewer, moreover, she should also know that the author does not temper the process by being its own reviewer or bringing in friendly reviewers. At this point, the scientific process becomes somewhat analogous to e-voting systems.
- 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 disincentivises the reviewers from participating and therefore is a drawback for the entire scientific process.
...
Since many sources can provide IRMA attributes, the IRMA platform does not standardize 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.
...
- 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 standardized 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.