InCommon metadata support

[Brian Larsen <>]

Thanks Scott,

I guess we are going to pioneer some of this then :)

You are correct in noting the library case, and it is mostly international, 
where budgets are often by department/faculty, motivating international 
institutions to license content from us to smaller sub units of the whole 
institution, but also want simultaneous authentication and authorization for 
their users against the main campus in the same handshake as they are 
authenticating against, say, the math department.

Appreciate your input. Spencer Thomas says hello and will be excited to be 
delving back into programming against the possibilities rather than a 
standard protocol. 

Best,

BRIAN LARSEN
Associate Director, Support Services
ITHAKA
734 887.7031


ITHAKA is a not-for-profit organization that helps the academic community use 
digital technologies to preserve the scholarly record and to advance research 
and teaching in sustainable ways. ITHAKA provides three innovative services 
that benefit the academic community: JSTOR, Portico, and Ithaka S+R.










On 5/26/16, 10:26 AM, 
"
 on behalf of Cantor, Scott" 
<
 on behalf of 
>
 wrote:

>> 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
>