...

Issuer: attribute aggregation from Research AAI/MMS

A membership managements system stores role and group information.

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

1. A logs in on the web interface of the MMS, a SAML SP and an account is created.
2. A creates a Virtual Organization / Community / Group - terminology depends on the actual tool but let's call it (VO)
3. A wants to invite Béla (B) to  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 comprimisedcompromised.
4. A sends an email invitation to B with a link containing a token.  The email is sent by the MMS system.
5. 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 federate 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.
6. After creating/accessing a local account, the token sent in the link is processed and B's account is now associated with the VO. 
7. B will eventually access a service that needs this membership information, commonly called entitlement.
   1. The service will perform a login flow
   and then
   2. with B's user identifier queries the MMS backend, 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.
8. 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.

With the introduction of DI4R, the flow may be significantly simplified. 

...

1. A creates a VO at the MMS service
2. A sends an invitation to B to the VO
   1. an email is sent to B from the MMS
   2. a card is registered to the registry?
3. B visits the link and receives the card, which is added to the wallet.
4. B visits a service that needs the entitlement and presents the card.
5. (the card is verified in the common registry, therefore revocation is possible

With this solution B does not have to use the same login (i.e. the MMS and the target S do not need to be in the same federation). Possibly, B can receive the card at a page maintained by the DI4R provider. 

Or, perhaps the DI4R provider's web interface serves as a landing page for the invitation?

Overview Use Cases

Sourcing

...