Proposed changes to eduGAIN SAML Profile

[nicoleharris]

In this proposed change the following issues have been added:

• Inclusion of a requirement for a Privacy Notice
• Inclusion of a requirement for a Security Contact
• Inclusion of a requirement for REFEDS Assurance and unique ID.

[daserzw]

Hi, thanks for this. I do agree with the proposed change, though I think the requirement for a Privacy Notice needs a change as currently it is marked as a SHOULD, while in order to be really useful we need a MUST for it, as we are currently doing for the other two requirements.

[peter-]

Hi, thanks for this. I do agree with the proposed change, though I think the requirement for a Privacy Notice needs a change as currently it is marked as a SHOULD, while in order to be really useful we need a MUST for it, as we are currently doing for the other two requirements.

The concrete use people (can) make of that element is quite different, depending on whether it's for SPs or IDPs, no?

For SPs, the referenced document needs to be publicly available (i.e., without prior authentication or IP-based restrictions) so that IDPs can render the mdui:PrivacyStatementURL to the subject before they even access the service, as part of some "consent"-like UI during login. (Though we may not be explicit about this requirement, today.)
We've also been publishing templates (since CoCo v1) for SPs suggesting what topics the referenced document should cover.

For IDPs, we have not made available any templates or other suggestions regarding the content — I'm guessing most IDP orgs will already have some data protection policy document published somewhere on their website, but that may only cover the processing done for their web site(s), of course.
And would this URL have to be publicly accessible? Contrary to the mdui:PrivacyStatementURL-for-SPs use-case I don't think it does — but of course monitoring for its existence (a secondary purpose at best, not its primary) becomes pointless/impossible if those URLs are not publicly reachable.

[nicoleharris]

Currently updated to be a MUST for SPs and a SHOULD for IdPs - happy for more feedback on this one

[peter-]

Currently updated to be a MUST for SPs and a SHOULD for IdPs - happy for more feedback on this one

Do you have a reference handy for the reasoning to mandate mdui:PrivacyStatementURL elements from IDPs? Without knowing that it's hard to move forward wrt SHOULD vs MUST.

[nicoleharris]

Currently updated to be a MUST for SPs and a SHOULD for IdPs - happy for more feedback on this one

Do you have a reference handy for the reasoning to mandate mdui:PrivacyStatementURL elements from IDPs? Without knowing that it's hard to move forward wrt SHOULD vs MUST.

The only relevant thing I can think of is that it would be an additional verification of the statement in the RAF to support the statement "You apply security practices to protect user information, safeguard transaction integrity, and ensure timely incident response" but there's no definitive link or requirement between the two. Otherwise I would consider it a "nice to have" and general good practice.

[peter-]

I see, that statement comes from RAF 2.0, 3. Conformance Criteria, item 4, which in turn is a direct quote of IPO4 from the REFEDS Baseline Expectations. Personally, I read that to be squarely related to information security (think SIRTFI) and not to privacy / data protection. I.e., I don't see how this would justify a requirement for a data protection policy or statement.
(Vice versa, a hypothetical list of third parties an IDP may be sharing my personal data with may be something I'd expect to find in a document referenced as mdui:PrivacyStatementURL, but cannot be gleaned from information security requirements.)

So unless we'll find other (or additional, on top of your "nice to have" and general good practice argument) reasons to make that a firm requirement from IDPs, I'd agree with keeping it as SHOULD.
(Especially when not making any statement about, or providing recommendations with regards to, the content of such a document — not having the element populated may in fact not be much worse than a referenced document with semi-unrelated enumerations of uses of data not relevant to identity federation. 😁)