1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Create a sensible privacy consideration section

Issue #90 resolved
Nat Sakimura created an issue

Need to make one. The current one is just a list of privacy principles.

SC27/WG5 SD4 and https://tools.ietf.org/html/rfc6973 should be consulted.

Comments (29)

  2. Tom Jones

    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.

  3. Nat Sakimura reporter

    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.

  10. Dave Tonge

    We discussed on the call today, and there seems to be a few questions to answer:

    1. Do we need a privacy considerations?
    2. Should they be high level principles or a step by step approach through the protocol (as the current PR does: https://bitbucket.org/openid/fapi/pull-requests/187)
    3. Should they be include normative shall clauses
    4. Should there be conformance tests with compliance with the privacy considerations
    5. 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.

  11. Dave Tonge

    My opinion:

    1. Yes we need privacy considerations
    2. They should be a step by step approach otherwise they aren’t that useful
    3. 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
    4. I think this would be interesting to discuss, but again maybe for FAPI 2?
    5. 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.

    ‌

  12. Dima Postnikov

    My opinion:

    1. Yes, we need privacy considerations.
    2. 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..
    4. conformance test to be used only when shall is used.

    ‌

  13. Joseph Heenan

    My take:

    1. Yes
    2. No strong opinion
    3. I don’t think so. They are considerations rather than requirements.
    4. I’m not sure how far automated tests can go.
    5. 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.)

    ‌

  14. Nat Sakimura reporter
    1. YES
    2. Step by step approach.
    3. 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.
    4. 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.
    5. 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.

    ‌

  15. Tom Jones

    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?

  17. Brian Campbell
    1. “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.
    2. No strong opinion but “sensible” as the ticket says seems like a good goal.
    3. Only if there’s a legitimate compelling reason
    4. Maybe but carefully consider the costs and value
    5. 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.

    ‌

  18. Nat Sakimura reporter

    SO, I have not heard any shout that any of the “shall” need to remain “shall”, so I will convert them to “should”.

  19. Nat Sakimura reporter

    Meta-question si whether we want this privacy consideration to be

    1. advice to the implementers; or
    2. statement of limitation of this document (aka excuse.)

    ‌

  21. Brian Campbell

    Part I still has the following in it, which should probably be reconciled during last call. Maybe move the new text from part II here to I and reference it from II. But I dunno.

    ** NOTE ** The following only has a boilerplate text 
specifying the general principles. More specific text 
will be added towards the Final specification.

    ‌

    ‌

    ‌

  30. Log in to comment
Assignee
Type
bug
Priority
critical
Status
resolved
Component
FAPI 1: Advanced
Milestone
3rd Implementers Draft
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!