[Fim4l] CoCo / attributes for authorization

[Peter Gietz]

One more thing on entitlement vs scoped affiliation: If we want to quote 
state of the art avangarde, we might also quote AARC documents, namely 
"Guidelines on expressing group membership and role information" [1], 
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". In that 
case the computation of the actual access rights would again be on the 
SP side based on the group or role information. Such a group could e.g. 
be member of the chemical department of University XYZ, who could be the 
only users interested in a chemical journal. This would not per se 
prevent interdisciplinarity, because a contract for that chemical 
journal could also include members in the department biochemistry or 
even biology.

A more general remark on this: the mode where SP computes is the defacto 
standard in SAML, which we can see that Attribute statements are very 
common and implemented, whereas authorization statements, specified in 
the same standard documents rather ist not.

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.

[1] 
https://aarc-project.eu/wp-content/uploads/2017/11/AARC-JRA1.4A-201710.pdf 
(October 2017)
[2] 
https://zenodo.org/record/2247446/files/AARC-G027-Specification_for_expressing_resource_capabilities.pdf?download=1

Cheers,
Peter

Am 21.03.2019 um 14:55 schrieb Peter Gietz:
> To summarize:
>
> In our recommendations:
>
> * we will reflect single and multiple contract cases
>
> * we will recommend common-lib-terms entitlement and scoped affiliation
>
> * we will recommend targetedID quoting chapter 2.2.11 of 
> eduperson201602 
> (https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(201602)-eduPersonTargetedID) 
> and its follow up attribute pairwise subjectID quoting chapter 3.4. of 
> the January 2019 specification 
> (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf)
>
> * we will address the fears of the library community and take over the 
> reasonable privacy related recommendations found in blogs from that 
> community
>
> It wasn't that stressful after all to reach so much consensus between us.
>
> @all can this be regarded as list consensus or are there more comments?
>
> Cheers,
>
> Peter  G.
>
>
>
>
> Am 20.03.2019 um 21:46 schrieb 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
>> _______________________________________________
>> Fim4l mailing list
>> Fim4l at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
>

-- 

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gietz at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz