Building a composite attribute from sets of attributes

[Etienne Dysli Metref]

On 06/08/2019 17.06, Cantor, Scott wrote:
>> There is, however, one case where this falls short: when a university
>> issues separate accounts for a person that is both student and staff.
> 
> I hate few things as much as I hate that practice.

We should have banned that practice 15-20 years ago when starting
SWITCHaai. We now hope to eliminate it with SWITCH edu-ID.

The SWITCH edu-ID aims at bringing a user-centric, i.e. single identity
to the individuals. So, this is a nice concept, but it hits reality
soon, mostly at the services which today most often assume *a specific
role or affiliation* when the user logs in. As a consequence, the edu-ID
has to deal with the different roles or affiliations of a single person.
One of the tools we developed for that situation is the affiliation
chooser: just before the attribute consent step, the user chooses one
affiliation, i.e. specifies the set of attributes to present to the
service, out of the stored affiliations they have (usually not that many).

Now that we have properly segregated the information about different
affiliations in our user directory on the IdP, we noticed that there are
actually services (!) that would want to profit from *all* that data at
once. They would be handed over all information about all affiliations,
and then make some sense out of it like, e.g.:

- a nationwide library system that replaces 500+ single library systems,
and that needs to know of individuals who are member of one or more of
those, with all their respective attributes properly segregated and not
lumped together;

- commercial services that want to support end users in finding a
suitable affiliation allowing them to use the service, or some part of
the service. Or the service defines usage quota based on the contracted
organisations, and the user wants to use the sum of allowed quota for
all organisations they are a member of.

BTW we are talking about the following affiliation-specific attributes
in particular:
- eduPersonScopedAffiliation
- mail (we've got values that stem from the organisations)
- swissEduPersonUniqueID (as it is issued by the organisation)
- later: eduPersonEntitlements and maybe group information

One can -- up to a certain point -- let the user choose the values.
However, this becomes difficult with the swissEduPersonUniqueID when the
user has two roles at the same organization, which would look too
similar. The more attributes a user has to pick, the less user friendly
and the more error-prone the whole process gets.

> I'm not sure I would argue that those attributes should really be 
> mixed; the whole point of that dual account strategy is to segregate 
> access and not lump the information together in one session. Nothing
> you want to notice that distinction will notice it and you're right
> back where you started.
That's what I meant: attributes from dual accounts should not be lumped
together, which is what OriginalIssuer would do.

>> Do you have time for a call to discuss this? I'm not sure I managed to
>> correctly explain what we are doing and want to achieve in writing.
> 
> I think I get it, but if you want time on a dev call to talk about
> it, that's fine (next one is Aug 16th, 10-12 EDT).
Great, thank you! We'll be there on the next call. We should stress
again that we're not expecting quick results here. For the time being
we'll be happy to see that our problem is understood by others.

Cheers,
  Etienne

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20190807/fbb3ad9a/attachment.sig>