faragom
commented
3 years ago I believe we are mixing concepts: all attributes in all profiles always have globally unique names, which are different from the friendlyNames we use for convenience.
We want to be able to request attributes from multiple sources. This is important, because source is not equal to profile (two sources could serve attributes from the same profile, and a source could serve attributes from more than one profile).
Next, the mention to the SSI module requires us to settle another definition: SSI module acts in some way as an aggregator of sources, so we need to differentiate source (where the attributes come from), from module (where the RM sends the request).
So now that we have settled the terms, my guess is that we want (correct me if I'm wrong):
The
RMto be able to request amoduleattributes from differentsources, assuming that thesourcesonly deliver attributes from one profile
If we don't make the last assumption, we need as well to differentiate the profiles, so 3 dimensions: attribute x profile x source. This would require us to use to the proper names of the attributes instead of the friendy names. I would avoid this for now, but the chance is always there.
So, we need to identify 2 things:
- The
moduleto query - Which source does every attribute belong to
For the 1st point, we already have spRequestSource parameter, so we are done
For the 2nd point, I propose scoping the request attributes. This way we dont need to implement anything new, nor do any heavy changes. So when requesting attributes, instead of this:
schacHomeOrganization
GivenName
mail
PersonIdentifierwe write this on the name/friendlyName fields of the request:
schacHomeOrganization@EduGAIN
GivenName@eIDAS
mail@EduGAIN
PersonIdentifier@eIDASThe other option would be to extend the attributeType object (spec) and include a scoping field, to include this information, but this will require changing pretty much code, and I would not recommend that now.
Also, as a comment for further work, this scoping to describe the source could be generalised to a syntax to search specific datasets or categories, which is something we've already discussed in other issues.
endimion
ross-little
Feature Request
Request attribute claims for multiple sources from the RM to the SSI Wallet It is needed to request multiple claims from multiple issuers e.g. eIDAS, eMRTD, eduGAIN from the RM to the SSI Wallet and it is supposed to use the /is/query with apRequest & apMetadata but this was supposing that there was one issuer of the data. So the dsResonse & dsMetada received in the call back to the RM pertain to one source. The attribute set received in the dsResponse also only contain one issuer and associated LoA etc for that one issuer.
Side issue A related issue is that there can be requested of attribute claims with the same name and it is not known which source that is requested e.g. family_name may be obtained from eMRTD or eIDAS so we need to determine how best we indicate the source that is requested, if a specific source such as eIDAS is requested
Describe Preferred Solution
To request attributes from the SSI Wallet It seems we need a new new type of request API e.g ssiRequest to the SSI module with the attributes returned to the RM in the dataStore.
To specify the exact claim source it must also either be clearly stipulated in the requested trust framework context in the ssiRequest e.g. context: @eidas or explicityly specify the uri of the claim e.g. http:seal.eidas.claims/family_name
@faragom @endimion @rcc-atos @mvj66 Ideas?