InCommon metadata support

["Cantor, Scott" <>]

> Apologies for the naivety of this question in advance.

Apologies for the lack of a useful answer in advance. I won't go into detail, 
I'm not sure this is the right list for that.

> Our initial expectation was that this information should be passed as 
> EntityID
> = institution, OrgId = sub unit. But, in at least one case, we are seeing 
> this
> distinction made in the ScopedAffiliation.

IdP != institution in general. Mostly it does, but there are both 1:n and n:1 
relationships possible there.

There is no standard way to really represent either organizations or subunits 
in any of this technology. Or any other. The use of DN-based attributes in 
eduPerson is just historical and largely irrelevant today. I don't know what 
you specifically mean by OrgId, but I'm guessing maybe it's a DN.

It was expected that one could use scoped affiliations to reflect this kind 
of thing, but that hasn't happened much in practice, and there's also no 
official sense in which scopes represent organizations either, though again 
that's a sort of assumption people make.

> Could someone with experience in this space point me at some best
> practices documentation and/or set me straight on this issue? Should both
> means of differentiation be expected and supported?

There are virtually none. It really is typically done with contract numbers 
in my experience. Most services don't want to know the internal 
organizational breakdown, they want to know who to bill. So that's more of a 
bilateral thing and has inhibited any real progress on the more abstract 
problem.

With respect to library cases, being that you're from Ithaka, there is 
essentially almost no use of fine-grained authorization by department in that 
space. It was imagined there would be, and if there had been, this sort of 
thing would have been solved.

-- Scott