[Fim4l] CoCo / attributes for authorization

[Peter Schober]

* Peter Gietz <peter.gietz at daasi.de> [2019-03-20 20:06]:
> Yes I know about entitlement common-lib-terms, and that it specially
> designed for libraries, and thanks for mentioning it, which I forgot, but I
> am not sure whether that will be the only entitlement that contracts will be
> based upon in the future.

I specifically mention it as superior and established replacement (or
alternative: like with identifiers one should be recommended and the
other still allowed; an SP should be able to check both) for
eduPerson(Scoped)Affiliation attributes.

> FIM will allow for more precise definition of users, which will make
> licenses cheaper for libraries. I may be wrong here, but I'd rather
> be corrected by librarians actually signing contracts.

If the use-case changes then my answer also changes.
But then you can't continue to only talk about
eduPerson(Scoped)Affiliation at the same time, becuase that also
doesn't handle new/different use-cases with more specific target
audiences.

So again: For the cases you mention ePSA use of the common-lib-terms
entitlement is superior for the reasons given earlier.
For other cases neither may be suitable (and certainly not ePSA).

> Yes its is good to have such an technical expert like you in this
> list, but please be aware that we have to also tackle non-technical
> issues here. And please be also aware that some people subscribed to
> this list are rather non-technical. It is ok to correct things, and
> I very much appreciate this, but we should not get too much into
> technical details. There are more appropriate lists for that.

Well, it's the guidelines that make statements about what attributes
to use for recoginising returning subjects (if needed) and for
authorisation -- even if it doesn't cleanly differentiate those
use-cases yet, so the guidelines are technically specific.
And if the choices made in that document are poor I will state this
and also explain why.
But I can limit myself to technical statements when suggesting
concrete wording changes in the document. It's just that for a
paper that should document shared agreement we'd have to agree first.
Hence I thought I'd open discussions on a few items.

> Yes we have new alternatives than targetedID, but I fear that
> attribute is still common practice and we should IMO name both
> targetedID and pairwise subjectID. Especially when RA21 only named
> targetedID.

I have no insight in what RA21 did and I'm sorry if that is one of the
results. I'm not finished in my fight against identifier chaos due to
continued co-existence of too many identifiers that do more or less
the same thing only differently.
The case-folding issue with eduPersonTargetedID (also affecting proper
persistent NameIDs and eduPersonUniqieID, btw) is the last straw, IMO.
But like I said, I'll try to get something going within the
federations community first.
-peter