When should the RM reurn linked identities in response to a SP Request?

[ross-little]

It is not exactly clear how the linked identities in the data store of type linkRequest are requested for an SP Request received at the Request Manager.

Should the spRequest be updated to specifically request them? Or alternatively for each identity requested to be obtained from the PDS/SSI source then the PDS / Wallet should also be queried for all linkRequests with the same dataSet Id included or maybe better on linkRequest with the dataSets including the type (eIDAS, eduGAIN , eMRTD etc?).

For the RM querying the PDS this is easier to achieve as the whole dataStore is available to be searched. For the SSI, this is implemented differently and is supported with no integration to the RM currently and needs the exact VC types to be queried, i understand.

Your thoughts? @faragom @endimion @mvj66 @rcc-atos

[faragom]

Hi,

As we discussed on the telco:

We allow the SP to request a specific IDP, we could make this value more complex, and allow to define a list of link sources to request. For example:

the SP now would request 'eIDAS'. We can redefine this as a URI syntax, that could allow us to prvide some extra information. For example, to request just the identity from eIDAS, the SP should request:

urn:mace:project-seal.eu:idsource:eIDAS

But this opens another issue: the wallet could include múltiple identities from a source for a user (for example, identitie from two universities in edugain, but also multiple identities from different eIDAS states). I would propose a hiearchy of identities. For example:

eIDAS;ES eIDAS;DE eduGAIN;uji.es eduGAIN;uaegean.gr PDS;eIDAS;ES --> this way we mark that the source we want to search this is from is the PDS directly, without accessing the source UPORT;eIDAS;ES --> this way we mark that the source is the SSI wallet (the part after UPORT should be defined by the VC module responsibles, just an example)

then, the SP could request

urn:mace:project-seal.eu:idsource:eIDAS --> to get any eIDAS identity

urn:mace:project-seal.eu:idsource:eIDAS;ES --> to get the eIDAS identity from Spain

[ the strings between the ':' characters, will be urlencoded, but here are described plaintext for clarity]

But, this has an implication: the ID on the dataStore must follow this same syntax (at least on the prefixes), so this clashes with the latest think I said about it. We need to raise this at a meeting and propose this small change.

Now, going back to the links:

we can add an optional field to this syntax, describing a list of identities whose links between the main identity and these are requested.

For example:

urn:mace:project-seal.eu:idsource:eIDAS;ES:links:eIDAS;DE,eduGAIN;uji.es --> this would request the spanish eIDAS identity, and request as well the link of it with the deustch eidas identity and the edugain identity from UJI.

El jue., 10 sept. 2020 a las 17:00, ross-little (notifications@github.com) escribió:

It is not exactly clear how the linked identities in the data store of type linkRequest are requested for an SP Request received at the Request Manager.

Should the spRequest be updated to specifically request them? Or alternatively for each identity requested to be obtained from the PDS/SSI source then the PDS / Wallet should also be queried for all linkRequests with the same dataSet Id included or maybe better on linkRequest with the dataSets including the type (eIDAS, eduGAIN , eMRTD etc?).

For the RM querying the PDS this is easier to achieve as the whole dataStore is available to be searched. For the SSI, this is implemented differently and is supported with no integration to the RM currently and needs the exact VC types to be queried, i understand.

Your thoughts? @faragom https://github.com/faragom @endimion https://github.com/endimion @mvj66 https://github.com/mvj66 @rcc-atos https://github.com/rcc-atos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EC-SEAL/request-manager/issues/19, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4HJ67FRZLN5SAVIRGRMM3SFDSYVANCNFSM4RFG7IDA .

-- Francisco José Aragó Monzonís mitsurugisan@gmail.com

[endimion]

Hey all,

For start I agree with Paco that the correct way is to specify the "IdP", however maybe we are over complicating things a bit...

I am not 100% sold that the we should be so fine grained and chew the SPs food for them. I mean if the SP wants an eIDAS eID from Spain they can check that the user is from ES from the personal identifier. Like wise for the edu attributes.

If they need a user to be from a specific institution, just ask for the user to provide the SP the institution and then the SP can decide.

What I mean by all this, is that maybe we should avoid too much SP business logic in the SEAL service. Thats the SPs business, else we need to support any case the SP might require for example; user is over 20years old, from Spain and has a phd form UAegean. We can cover it with Pacos approach but why put our selves into such situations in the first place :)

[faragom]

Yes, but the problem are the links. The user chooses to get auth from eIDAS. Should we send along all the links the eIDAS dataset has with other datasets? If we send them all, we are violating minimisation principle from GDPR. In the most basic behaviour (the SP does not specify anything), the user will be able to select which data sets from the dataStore to add to the response. But if we want the SP to be able to select a source, we should also let the SP select which link(s) they need along it.

We can simplify for now, and just let the user decide, but at least we need to let the SP mark that it wants a source, and "links", to let the RM know that it has to load a dataStore. The syntax I propose can be incremental. For example:

urn:mace:project-seal.eu:idsource:eIDAS --> to get any eIDAS identity and not load a dataStore

urn:mace:project-seal.eu:idsource:eIDAS:links--> to get any eIDAS identity and then load a dataStore to let the user choose a link or more to return along.

The syntax is still compatible with all of the above, new logic can be added later without affecting the existing one but for the moment we implement only these two options, that give the most basic functionality still covering the needs.

[ross-little]

When you indicate idsource:eIDAS I preume you mean the previously agreed spRequestSource? Ref: https://github.com/EC-SEAL/interface-specs/wiki/session-variables

Remember that the design of the SEAL RM is to only request from one source and does not provide aggregated identities from different data sources.

Or is requesting idsource:eIDAS:links giving the freedom to the user to select any source to retrive the eIDAS identity and if that source supports links to also provide any links it has for the requested identity? NB only the SSI wallet or PDS will support identity links.

Should the RM also indicate then that all linked information should be provided?

Thinking more on privacy minimisation it does seem important that there should be a query parameter for links supporting possibly all links or just specific links like eduGAIN.

[faragom]

Hi,

El lun., 14 sept. 2020 a las 16:39, ross-little (notifications@github.com) escribió:

When you indicate idsource:eIDAS I preume you mean the previously agreed spRequestSource? Ref: https://github.com/EC-SEAL/interface-specs/wiki/session-variables

Yes, I mean this would be the value of spRequestSource, but instead of a simple string, use this uri scheme

Remember that the design of the SEAL RM is to only request from one source and does not provide aggregated identities from different data sources.

Well this proposal was a way to provide a better usability, but maybe we should go back to the original idea fro now and leve these improvements for later.

So, then we should resort back to:

1. if an SP wants eIDAS auth + eIDAS - UJI link, it has to do a:
2. auth request with: spRequestSource= eIDAS
3. query request with: spRequestSource= PDS to open the pds load, and let the user select the link objects to return

Agreed?

Or is requesting idsource:eIDAS:links giving the freedom to the user to

select any source to retrive the eIDAS identity and if that source supports links to also provide any links it has for the requested identity? NB only the SSI wallet or PDS will support identity links.

Should the RM also indicate then that all linked information should be provided?

Thinking more on privacy minimisation it does seem important that there should be a query parameter for links supporting possibly all links or just specific links like eduGAIN.

We can improve this later. First let's have the basics running.

So for example the SP could request

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EC-SEAL/request-manager/issues/19#issuecomment-692102298, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4HJ6ZQ4XQ6NOHAF4JRLXLSFYTLVANCNFSM4RFG7IDA .

-- Francisco José Aragó Monzonís mitsurugisan@gmail.com

[endimion]

Yes let us have the basic case running and we can discuss improvements later on :+1:

[ross-little]

Ok agreed, for now.

Just to note I think the normal scenario in SEAL is for the SP to query the user's identity from the user's trusted SEAL credentials from his/her PDS or SSI Wallet and in this case it is easy to also return any linked credentials, with no impact on usability.

To do the live authentication I think we should keep it as a simple authentication against any of the SEAL supported auth sources and only to be used occasionally e.g. the SP wants to do a further check for some policy reason. So not to request live authenticaion with linked credentials as a normal case but something that the SP can do when it sees the need e.g. on initial registration and they have the ability to do this in separate requests to SEAL.

[faragom]

Hi,

El mar., 15 sept. 2020 a las 8:25, ross-little (notifications@github.com) escribió:

Ok agreed, for now.

Just to note I think the normal scenario in SEAL is for the SP to query the user's identity from the user's trusted SEAL credentials from his/her PDS or SSI Wallet and in this case it is easy to also return any linked credentials, with no impact on usability.

Yes, but depends on the use case and the trust needs. Here lies another issue for the future: to raise the trust on the authentication from the dataSets stored on the PDS, we need to design a revocation system. This way, we can extend the lifetime of the retrieved datasets without affecting the trust level,as the source could revoke them anytime.

but since it's the user who has to select, he might forget something and stuff. The improvement would allow for the user just to confirm the pre-selected items.

To do the live authentication I think we should keep it as a simple

authentication against any of the SEAL supported auth sources and only to be used occasionally e.g. the SP wants to do a further check for some policy reason. So not to request live authenticaion with linked credentials as a normal case but something that the SP can do when it sees the need e.g. on initial registration and they have the ability to do this in separate requests to SEAL.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EC-SEAL/request-manager/issues/19#issuecomment-692494601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4HJ626MX7V5NMEKAWU7ZTSF4CGFANCNFSM4RFG7IDA .

-- Francisco José Aragó Monzonís mitsurugisan@gmail.com