Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Tommy,

That sounds okay with me.   Thanks for clarifying.

Regards,
Rob

From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Sent: 22 June 2020 17:25
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: capport-chairs@ietf.org; captive-portals@ietf.org; The IESG <iesg@ietf.org>; draft-ietf-capport-api@ietf.org; Martin Thomson <mt@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.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@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