Subject RE: eduPersonSubjectIDGUID
From Eric Goodman <Eric.Goodman@xxxxxxxx>
Date Thu, 22 Oct 2015 23:40:42 +0000

>Has anyone who is interested in this conversation on either of these lists, and wants to

>solve this problem, not gotten a chance to look at Nate's "Dogma," or couldn't understand

>it?  It took me a while to understand it (not sure I still fully do).  It's worth a read and a

>sleep-on-it (or in my case, several dozen sleeps-on-it) if you haven't.


[Responding not JUST to this comment, but I’ll start here]


Pretty confident I have not slept on it enough, but I have read it.


The way I think of it (logically, not technically) is that if “privacy protection” is desired, but we also want PPIs (Pairwaise Pseudonymous Identifiers) used as much as is feasible, then what VOs and others really need is a way to dynamically “affiliate” SPs.


That is, today’s process for affiliating of SPs – which as I understand it is asserted statically in metadata – will run into the similar concerns to some that were raised in the “academia” categories discussion, namely that for some of these problems, making policy statements about users at the IdP level is too coarsely grained.


What would be ideal for privacy is PPIs where the user can dynamically control the affiliation scope of their PPIs, i.e., I tell or have some consent interface to approve the IdP correlating me across a set of SPs. I don’t have any (elegant) technical approach for implementing, or any elegant UIs for gathering user consent, but that does seem like the “right” level of control if we had the right technology and UI around it. (An ID that’s literally an attribute bundle of all the IDs that the SP is allowed to correlate?)


I think that thinking is vaguely in line with Nate’s ideas, though it sounds to me like Nate’s suggestions are more around dynamic management of persistent IDs across multiple IdPs, whereas my statement above is more about management of persistent IDs within one IdP (though exposed to many SPs). And I’m not sure if the “persistent” in Nate’s example is “PPI” vs. just “non-reassigned”.


The challenge I see to Nate’s suggestions (as I understand them) are less about technology and more about the trust frameworks. Under what circumstances would I trust your IdP to assert one of your users as the same person as one of mine? If the answer is too restrictive, then that puts a cap on the value of the service.


--- Eric