[Fim4l] CoCo / attributes for authorization

[Peter Schober]

* Peter Gietz <peter.gietz at daasi.de> [2019-03-21 16:26]:
> AARC document
> "Guidelines on expressing group membership and role information"

FWIW, I think none of that matters here for two reasons.

One is due to the lack/violation of the first item in its "General
guidelines" which presumes the existance of a proxy component that
alone has to deal with (and can therefore abstract away from the SPs)
the complexity and heterogenity of group information in multi-party
federation.  I.e., the document acknoledges that its a mess
("Harmonisation of naming for groups, hierarchy and use of ontologies
within different scientific domains is explicitly excluded from these
guidelines.")  but claims it can be made usable with proxies.  There
are no such proxies in FIM4L.

> which recommends the usage of eduPersonEntitlement in a different
> way than defined in eduPerson, namely to contain group or role
> information instead of "indicat[ing] a set of rights to specific
> resources".

I wouldn't put too much into the original wording as the envisaged
use-case for ePE never happened (due to some of the issues I already
commented on), I think. There are mainly two kinds of ePE usage AFAIK:

* The common-lib-terms standardised, invariant attribute value.
  (There are hardly any other "standard" values. Even very commonly
  used values such as the TCS "urn:mace:terena.org:tcs:personal-user"
  and "urn:mace:terena.org:tcs:escience-user" ones are
  contract-specific and so fall under the next category.)
* Values that are somewhat private/bilateral/tied to a *specific*
  contract (instance) and will need to be agreed upon in each case.
  I think all cases of the Czech "multiple contracts for the same
  resource an institution has with an e-resource provider" fall under
  that, among others.

So the second reason this AARC paper doesn't apply or matter here is
that it's doubtful /any/ kind of standardization of attribute values
in this area can make meaningful contributions to the latter cases:
Standardising how one IDP sends its local groups tells the SP nothing
about /which/ of those groups should be considered to be covered under
a given contract -- each IDP will still have to tell the/each SP
specifically which of those "groups" (i.e., strings to match) should
be allowed (and for what product). (Only sending the ones that
constitue pre-authorized groups is going back to the IDP
pre-calculating those rights, which is an anti-pattern in FIM.)

The specific set of "considered authorized" groups/string values will
necessarily be different for each IDP (at each SP) and likely
different for each SP (at each IDP) there's not much that can be
gained from standardization.
(Note that there's also no global ontology for "departments" or "org
units in academia" or whatever that would allow to automate parts of
that parsing and decision making. No DCC etc. to help here.)

> On the other hand we should IMO not recommend (to libraries, our
> target group) to use another AARC result, namely "Specification for
> expressing resource capabilities" from December 2018[2] which is
> more in-line with the original idea of eduPersonEntitlement, namely
> defining access rights to resources.

It does match exactly the library use-case (access to licensed
resources), though. Obviously an IDP cannot enumerate all the
resources (which are at the SP!) its own local groups/communities may
have access [rights] to, but if <RESOURCE> is an identifier for a
contract with an SP that doesn't sound unreasonable?

But reason number two above still applies, so the notational or
semantic specifics don't matter.

-peter