Hi Tommy,
That sounds okay with me. Thanks for clarifying.
Regards,
Rob
From: Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>
Sent: 22 June 2020 17:25
To: Rob Wilton (rwilton) <rwil...@cisco.com>
Cc: capport-cha...@ietf.org; captive-portals@ietf.org; The IESG
<i...@ietf.org>; draft-ietf-capport-...@ietf.org; Martin Thomson
<m...@lowentropy.net>
Subject: Re: [Captive-portals] Robert Wilton's No Objection on
draft-ietf-capport-api-07: (with COMMENT)
Hi Rob,
Thanks for the example text for user consent, etc. I believe that at this point
in how the CAPPORT API will be used, the main way that personal information is
transmitted is in the web portal. The privacy text in -08 was updated from the
-07 version to not imply that it is the API JSON itself:
"Information passed between a client and the user-facing web portal
may include a user's personal information…”
My interpretation of requirements like GDPR is that they’d be then applying to
what shows on the web portal that the API server points to, at which point the
consent and terms can and should be shown in a normal web page flow.
However, for future extensions to the CAPPORT API that could allow captive
portal interaction without a webpage, but done more “automatically”, I do think
this kind of text will be necessary. So, I think for now, we leave this for
future updates?
Best,
Tommy
On Jun 22, 2020, at 9:18 AM, Rob Wilton (rwilton)
<rwilton=40cisco....@dmarc.ietf.org<mailto:rwilton=40cisco....@dmarc.ietf.org>>
wrote:
Hi Tommy,
Just one (belated) comment at the end ...
7.1. Privacy Considerations
Possibly worth adding a comment about the necessity to keep personal
information secure. In addition, should there be any comments about
GDPR like
constraints (if they apply)?
This section has also be reworded slightly to make this more clear. I’m
not sure if there’s anything we can state for GDPR or similar constraints
here. I think that would mainly apply to what is shown in the user portal,
not the API interaction.
[RW]
FWIW, I saw this text in another document that I'm reviewing now, and is was
something along these lines that I was originally thinking of when I posted the
original comment:
When sharing personally identifiable information or information that
is otherwise considered confidential to affected users, SET
Transmitters and Recipients MUST have the appropriate legal
agreements and user consent or terms of service in place.
Furthermore, data that needs confidentiality protection MUST be
encrypted, at least with TLS and sometimes also using JSON Web
Encryption (JWE) [RFC7516].
In some cases, subject identifiers themselves may be considered
sensitive information, such that their inclusion within a SET may be
considered a violation of privacy. SET Issuers should consider the
ramifications of sharing a particular subject identifier with a SET
Recipient (e.g., whether doing so could enable correlation and/or de-
anonymization of data) and choose appropriate subject identifiers for
their use cases.
I.e. if user identifiable information is being carried over the CAPPORT API,
then IANAL, etc, but I think that GDPR would require that the user had given
consent in some way before any personally identifiable information is
transmitted.
I'll leave it to you to decide if that is a valid consideration for the privacy
section.
Regards,
Rob
Best,
Tommy
Thanks,
Rob
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
