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

[Tommy Pauly <[e-mail]>]

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=[e-mail]> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>