[Fim4l] CoCo / attributes for authorization

[Raoul Teeuwen]

Although the opinion of librarians is more relevant: thank you 2 Peters for the discussion!!! Thank you for the summary as well. I think I read Peter S would rather recommend pairwise subjectID, with targetedID as 2nd best for as long SP’s are not able to use the recommended id? So those should be switched in the summary below?

Kindest regards,

Raoul
 tel:+31641195989

On 21/03/2019, 14:57, "FIM4L on behalf of Peter Gietz" <fim4l-bounces at lists.daasi.de<mailto:fim4l-bounces at lists.daasi.de> on behalf of peter.gietz at daasi.de<mailto:peter.gietz at daasi.de>> wrote:

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<mailto: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<mailto: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<mailto:peter.gietz at daasi.de>
web:   www.daasi.de

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

_______________________________________________
FIM4L mailing list
FIM4L at lists.daasi.de<mailto:FIM4L at lists.daasi.de>
http://lists.daasi.de/listinfo/fim4l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20190321/fa3e8cd2/attachment.html>