i never understood the privacy considerations of the openid connect doc. In part because none of them seemed to be requirements, or to relate to what a user actually experienced. I copy the first two of them below as an anti-pattern for future considerations and to start a discussion of whether any privacy considerations should be mandatory. Perhaps this is an argument for a separate document that could be separately adopted and then could contain SHALL rather than SHOULD.
The UserInfo Response typically contains Personally Identifiable Information (PII). As such, End-User consent for the release of the information for the specified purpose should be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the redirect_uris.
Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement.
The Resource Server SHOULD make End-Users' UserInfo access logs available to them so that they can monitor who accessed their data.
Note should be removed. Others seem OK from the reporter's point of view.
Tom: if you have specific text proposal, please create a new ticket.
Should there be conformance tests with compliance with the privacy considerations
Should they assume the reader is familiar with ISO/IEC 29134 and ISO/IEC 29100
It would be good to get feedback from the WG on these questions.
Yes we need privacy considerations
They should be a step by step approach otherwise they aren’t that useful
I don’t think in FAPI 1.0 that any clauses should be normative shall s - I think these should be recommendations for FAPI 1, but for FAPI 2 we can make them into shalls
I think this would be interesting to discuss, but again maybe for FAPI 2?
I have a bit of a problem with the reliance on the ISO standards - they are not very accessible. 29100 is publicly available but only via a zip download. 29134 is not publicly available and needs to be purchased.
Yes, we need privacy considerations.
High level principles at a minimum. May be we should start there? Step by step approach might be included for some items where there is an agreement..
conformance test to be used only when shall is used.
No strong opinion
I don’t think so. They are considerations rather than requirements.
I’m not sure how far automated tests can go.
I think it would be good if we could provide definitions of PII & PII principal (I’m not sure if legally we could just include the relevant ISO definition text within FAPI?). It might be that some of the clauses mentioning ISO specs should be a bit weaker, e.g. changing “the client shall create a privacy notice following the guidance given in ISO/IEC 29184. ” to “the client should create a privacy notice, for example by following the guidance given in ISO/IEC 29184.“ (I’m not really familiar with 29184, but I wonder if there will be cases where people don’t follow it’s guidance for good reasons.)
Step by step approach.
I am fine with turning all shall to should but we need a rather careful examination and qualification on the text not to step on some of the sensitive issues. I have put shall there to draw readers attention which I was successful.
Yes, if we get sponsors, although what we can do for automated testing could be rather limited. Still, making sure that the registration includes policy_url for example and application for the certification including a statement that the applicant believes that they follow for example ISO/IEC 29184 is a big step forward and has legal teeth.
If there are alternative standards that were vetted and endorsed by privacy regulators/authorities from all over the world, then I am fine with replacing them. Otherwise, I believe we should keep referencing them as recommended documentation.
PII is a legal term from the GDPR. It really doesn’t matter how you define it. Also its meaning is constantly shifting as various courts make random contributions to the lexicon. Is it any surprise that privacy professionals are mostly lawyers?
Actually, GDPR’s term is “personal data” not PII.
“need” is overstating it but sure. With the caveat that there was some idea of taking this stuff to final soon so introducing over a dozen normative MUST/shalls is problematic at this point.
No strong opinion but “sensible” as the ticket says seems like a good goal.
Only if there’s a legitimate compelling reason
Maybe but carefully consider the costs and value
I am certainly not familiar with ISO/IEC XXXXXX and I’d be surprised if I was an anomaly in that regard. “referencing them as recommended documentation” is one thing but putting hard normative requirements on content in documents that are not easily accessible is another thing all together.
SO, I have not heard any shout that any of the “shall” need to remain “shall”, so I will convert them to “should”.
Meta-question si whether we want this privacy consideration to be
advice to the implementers; or
statement of limitation of this document (aka excuse.)