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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 11 Jun 2020 04:17:41 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-capport-api-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-api/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I found this document straight forward and easy to read.

Linda's comment in the Opsdir review is interesting.  I would have expected the
CAPPORT architecture document to discuss/reference the problem being solved,
but it seems to be mostly silent on this.  I will redirect Linda's comment to
the CAPPORT architecture.

In section 5. "API State Structure", it does not state whether a connection
could be both time and data limited.  My reading of the spec is that this would
be allowed, assuming that is the case, the current text is fine.

6.  Example Interaction

   Upon receiving this information the client will use this information
   direct the user to the the web portal (as specified by the user-
   portal-url value) to enable access to the external network.  Once the
   user satisfies the requirements for extenal network access, the
   client SHOULD query the API server again to verify that it is no
   longer captive.

Nit: information direct => information to direct

7.  Security Considerations

I'm slightly concerned about the third paragraph in the security
considerations.  Ideally I would like a solution that doesn't require humans to
potentially spot potentially dubious spoofed domain names.  But I can
appreciate that is probably out of scope here.

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)?

Thanks,
Rob

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Jun 2020 10:05:15 -0700

Hi Rob,

Thanks for the review!

Responses inline. You can also see updates in our working copy here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html

> On Jun 11, 2020, at 4:17 AM, Robert Wilton via Datatracker <[email-masked]> wrote:
> 

Correct, there is no requirement that time and data limits are mutually exclusive.
> Nit: information direct => information to direct

Fixed on latest working copy.
> appreciate that is probably out of scope here.

This has been removed and reworded in our working copy, from addressing Ben’s comments.
> 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.

Best,
Tommy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 22 Jun 2020 16:18:30 +0000

Hi Tommy,

Just one (belated) comment at the end ...

> -----Original Message-----
> From: Tommy Pauly <[email-masked]>
> Sent: 11 June 2020 18:05
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; capport-
> [email-masked]; [email-masked]; Martin Thomson
> <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-capport-api-07:
> (with COMMENT)
> 
> Hi Rob,
> 
> Thanks for the review!
> 
> 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

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Jun 2020 09:25:24 -0700

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=[email-masked]> wrote:
> 
> Hi Tommy,
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 22 Jun 2020 16:38:43 +0000

Hi Tommy,

That sounds okay with me.   Thanks for clarifying.

Regards,
Rob

From: Tommy Pauly <tpauly=[email-masked]>
Sent: 22 June 2020 17:25
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; Martin Thomson <[email-masked]>
Subject: Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Rob,

Best,
Tommy

On Jun 22, 2020, at 9:18 AM, Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>> wrote:

Hi Tommy,

Possibly worth adding a comment about the necessity to keep personal
information secure.   In addition, should there be any comments about
GDPR like

Regards,
Rob

Best,
Tommy

Thanks,
Rob

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals