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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Tommy,

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

> -----Original Message-----
> From: Tommy Pauly <[e-mail]>
> Sent: 11 June 2020 18:05
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; capport-
> [e-mail]; [e-mail]; Martin Thomson
> <[e-mail]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-capport-api-07:
> (with COMMENT)
> 
> 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
> <[e-mail]> wrote:
> >
> > 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.
> 
> Correct, there is no requirement that time and data limits are mutually
> exclusive.
> >
> > 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
> 
> Fixed on latest working copy.
> >
> > 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.
> 
> This has been removed and reworded in our working copy, from addressing
> Ben’s comments.
> >
> > 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
> >
> >
> >