* Peter Gietz <peter.gietz@daasi.de> [2019-03-21 14:55]:
> * we will recommend common-lib-terms entitlement and scoped affiliation

One vital missing piece here is to recommend (though I'm in favor of
much stronger wording) that authorization is actually performed by the
SP based on transmitted attributes.
I.e., "We don't need no attributes" should not be acceptable.

While there may be cases where indeed "everyone and everything that
can authenticate" at an institution is covered by the contract (I know
of exactly one such case) even then tying the contract to the IDP's
entityID (there's nothing else to tie it to without any attributes) is
an anti-pattern: Not every institution runs/maps to exactly one
entityID.

In the vast majority not processing any attributes (as part of
federated logins) will simply mean the SP expects the IDPs to only
sends authorized subjects to the SP (i.e., abort SSO for those
subjects which should not be allowed access to the SP according to the
SP's rules), which does not scale: Federation is based on the IDP
performing authentication and asserting things and the SP performing
authorization based on the asserted data.

An SP not looking at any attributes makes it impossible for an IDP to
tell the SP that someone should NOT be able to access licensed
resources on behalf of the institution.

Should the IDP not completely block access to the SP that then creates
a legal risk and potential fingerpointing between the SP ("The IDP
should not send us unauthorised people") and IDP ("The SP should look
at the data we sent were its clear the person is not authorized").

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

That would directly go against saml2int that has had an RFC-SHOULD
there for many years:

"If an opaque targeted user identifier is being provided to the
Service Provider, it is RECOMMENDED to use a <saml2:NameID> construct
with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
rather than transporting that identifier as an <saml2:Attribute>."
( https://saml2int.org/profile/current/#section7 )

It would also ignore the new saml2int which has much stronger language
on not requiring any NameID or Attribute for identification.

But give me a couple of days/week to find out whether the former can
be formally deprecated or something else to that effect.
Our deployment profiles have been speaking out against ePTID for many
years now, it's time to close that chapter.

-peter
_______________________________________________
FIM4L mailing list
FIM4L@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l