...
- 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 provider: Providers need not to federate - they can decide to consume or stop consuming user information at any time and it is only up to the user whether they want to provide attributes or not.
- 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.
- Easier compliance with GDPR:
- The user holds control over cards and can easily delete them
- For the IdP there is no not much difference (actually can be less good, less control - the IdP cannot know/limit what happens with the credentials once issued.
- Not having a proxy! is a big advantage with regards to the GDPR
- SP is responsible for asking for only what it needs, and in an IRMA-like system you always get what you ask for
- 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
...
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.
In this arrangement, the sole source of all information is the Proxy from the SP's point of view.
...
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).
- A logs log in on the web interface of the MMS, a SAML SP and an account is created.
- A creates a Virtual Organization / Community / Group - terminology depends on the actual tool but let's call it (VO)
- A wants to invite B to his VO. In order to do this, he needs an email address to B. This email address serves as a trust anchor for the moment, therefore it needs to really belong to B and not be compromised.
- A sends an email invitation to B with a link containing a token. The email is sent by the MMS system.
- B follows the link to the web interface of the MMS, prompted for login. B may already have a login (for previous participation in other VOs) or needs to create a new one. B may log in with a federated account but it could be the case that there is none, and a local account is created or a VHO account is used. This scenario is made possible by the fact that really the access to the email inbox is what provides the trust for the VO membership.
- After creating/accessing a local account, the token sent in the link is processed and B's account is now associated with the VO.
- B will eventually access a service that needs this membership information, commonly called entitlement.
- The service will perform a login flow
- with B's user identifier queries the MMS back-end, for instance, a SAML AA or an integration. This requires the usage of the same user identifier that was used at the MMS, typically a common OIDC/SAML source.
- A may revoke the entitlement at any time, which will take effect at the next session: the service accessed will query the MMS and will not get the entitlement.
...
- 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-anonimity 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 in of the journals in question.
...
The Virtual Home Organization use case helps users wanting to access research & education infrastructure without having a home organization that is technically enabled with the accessed services on a technical level. While the technical integration is missing, the user may have a completely valid claim on access. In these cases, a virtual home organization (VHO) is used. In this description, we present the sponsored VHO use case, in which one user (within the technical collaboration) sponsors another (outside the collaboration) by an invitation.
...
The user may select what credentials from available they want to present to the verifier. The verifier can determine itself which attributes it does or does not accept from which sources. It can also state the required attribute bundles by using IRMA "Condiscons" (CONjunction of DISjunctions of CONjunctions), which allow verifiers to specify attributes sets coming from a single credential instance. With this, a service can require a composition of alternative bundles of attributes, even if they are using different schemes to provide the relevant data and corresponding LoAs. However, the use of a consistent attribute schema and semantics of levels may greatly simplify this selection, along with a mechanism informing verifiers about trustworthy issuers participating in such a schema.
...
Most of the currently trending second-factor options assume the primary channel to be a desktop or laptop computer and the mobile as a secondary device.
However, IRMA is a mobile-only application, and, obviously, no user will have a second mobile device that may act as an independent source of authentication.
...
Another important factor to consider is the very nature of the distributed identity system - there is are no huge amounts of sensitive data on any one device, instead, all the devices store their owner’s data only, making them much less valuable targets.
...
Besides all this, the mobile device is much more personal than the desktop or laptop device , and is much better tied to the user, also, by the virtue of providing the primary means of personal communication, a mobile device is much sooner reported and their connection remotely deactivated when stolen or lost.
This shows that the lack of a second-factor option in the case of a mobile wallet may be compensated by other factors.
...
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
...
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 distribute distributes issuer-related information that is updated at the time of revocation and is necessary to disclose attributes.
...
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 IRMA daemon using the result of the issuance session request and shows the result.
...