[Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-capport-api-07: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

“Discuss discuss”.  Section 4 says “The API server endpoint MUST be accessed
using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].”  There
is also various guidance on verifying the API server identity and access to
revocation and time resources.  However, the way I read the definition of the
“Captive Portal API Server” per Section 2 and per Figure 1 of
draft-ietf-capport-architecture, the API server is logically different than the
service at the user-portal-url URL (i.e., Web Portal Server in the
architecture).

Section 7.1 helpfully points out “Information passed between a client and a
Captive Portal system may include a user's personal information, such as a full
name and credit card details.  Therefore, it is important that Captive Portal
API Servers do not allow access to the Captive Portal API over unencrypted
sessions.”  The first sentence is makes sense, but the second, while true,
doesn’t follow the first for me.  PII and credit card information would be the
kind of input you would provide to the _Web Portal Server_ not the Captive
Portal API (of course both are part of the overall Captive Portal system).  I
feel there is missing guidance roughly on the order of the user-portal-url
“provides the URL of a web portal _that MUST be accessed over TLS_ with which a
user can interact.” (and the venue-info-url SHOULD use TLS too).

Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally
providing pointers to other resources.  Would it be out of scope for this
document to place restrictions on what the API is capable of pointing to?  If
not here, then where?


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

Thanks for describing the protocol interaction within the reference
architecture of draft-ietf-capport-architecture.

** Ben points to a few places to tighten up the TLS mechanics (e.g.,
referencing BCP195, non-OCSP stapling revocation) which I won't repeat here. 
These are important.

** Are there any retry behavior to specify for the client?  Say the client
tries to the visit the API URL and the server returns an HTTP 500 error? Or,
the API server doesn’t respond at all?

** Editorial Nits

-- Section 4.1. Typo.  s/mechnism/mechanisms/

-- Section 6.  Typo.  s/the the/the/

-- Section 6.  Typo. s/extenal/external/