* Jiri Pavlik jiri.pavlik@mzk.cz [2019-05-13 17:36]:
I like the idea of releasing eduPersonEntitlement as a default, pairwise-id, mail and name with user consent.
But this (option 4 in my email) is not really technically feasible today. I can go into more details about how this would need to be implemented at an (every!) IDP but atm it's a not very clean or easy combination of local configuration plus metadata plus well-chosen software defaults.
From SP point of view eduPersonEntitlement as required attribute, pairwise-id, mail and name as optional attributes. When pairwise-id is not provided by IdP based on user consent no personalisation features are offered for the user.
My question is how would that be any different from what we have today? Each SP can declare what attributes it needs and whether they're required or optional. (Let's ignore foe now the fact that not all federations offer this distinction or that it doesn't work for all all cases.) Some IDPs then create release policies that release required attributes only, others that release required and optional ones. All of that exists today (plus more: IDPs not releasing anything, IDPs releasing too much, SPs not requesting anyting or not in an optimal way, SPs requesting too much).
And can all SPs we're interetested here live with option 2: No stable identifer, no personalisation? Because of the issues when asking subjects to create Yet Another Username and Password (2.1 to 2.3) personalisation outside of the federated login is something of a worst-case scenario. I have no idea how many SPs would actually break (and to what degree) without any stable identifier present? I can look into eduGAIN metadata but from samples you have posted earlier we've already seen how unreliable that data often is. (Which btw is nothing to accept, any instance of this is a bug and should be reported to the federation publishing such metadata.)
-peter