Draft: draft-ietf-capport-architecture

Commentary: This replaces any ' URL ' terminology with ' URI ' . It also adds an informative reference to RFC 3986 , as suggested . Fixes issue 
 Multiple reviewers have suggested that we use URI instead of URL . I think we should make this change , and add the informative reference .
Here we discuss candidate mechanisms for provisioning the User
Equipment with the URL of the API to query captive portal state and
navigate the portal.
A standard for providing a portal URL using DHCP or Router
Advertisements is described in RFC7710bis.  The CAPPORT architecture
expects this URL to indicate the API described in section_api.
Although still a work in progress, I-D.pfister-capport-pvd proposes a
mechanism for User Equipment to be provided with PvD Bootstrap
Information containing the URL for the JSON-based API described in
section_api.
Here we discuss candidate mechanisms for provisioning the User
Equipment with the URI of the API to query captive portal state and
navigate the portal.
A standard for providing a portal URI using DHCP or Router
Advertisements is described in RFC7710bis.  The CAPPORT architecture
expects this URI to indicate the API described in section_api.
Although still a work in progress, I-D.pfister-capport-pvd proposes a
mechanism for User Equipment to be provided with PvD Bootstrap
Information containing the URI for the JSON-based API described in
section_api.
The URL of this API will have been provisioned to the User Equipment.
(Refer to section_provisioning).
The URI of this API will have been provisioned to the User Equipment.
(Refer to section_provisioning).
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URL for the Captive Portal Server.  The API SHOULD provide evidence
to the caller that it supports the present architecture.
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the Captive Portal Server.  The API SHOULD provide evidence
to the caller that it supports the present architecture.
The URLs provided in the API SHOULD contain all the information
necessary to render the resources requested: the resources should not
depend on ambient information, such as remote address on the
connection.  This is to ensure that the content served from these
URLs is correct and meaningful to the User Equipment, even when
accessed from a network other than the one that contains the captive
portal.  One consequence of this is that URLs provided in the API are
expected to be resolved using public global DNS (as defined in
Section 2 of RFC8499).
Though a URL might still correctly resolve when the UE makes the
request from a different network, it is possible that some functions
could be limited to when the UE makes requests using the captive
network.  For example, payment options could be absent or a warning
could be displayed to indicate the payment is not for the current
connection.
URLs could include some means of identifying the User Equipment in
the URLs.  However, including unauthenticated User Equipment
identifiers in the URL may expose the service to spoofing or replay
attacks.
The URIs provided in the API SHOULD contain all the information
necessary to render the resources requested: the resources should not
depend on ambient information, such as remote address on the
connection.  This is to ensure that the content served from these
URIs is correct and meaningful to the User Equipment, even when
accessed from a network other than the one that contains the captive
portal.  One consequence of this is that URIs provided in the API are
expected to be resolved using public global DNS (as defined in
Section 2 of RFC8499).
Though a URI might still correctly resolve when the UE makes the
request from a different network, it is possible that some functions
could be limited to when the UE makes requests using the captive
network.  For example, payment options could be absent or a warning
could be displayed to indicate the payment is not for the current
connection.
URIs could include some means of identifying the User Equipment in
the URIs.  However, including unauthenticated User Equipment
identifiers in the URI may expose the service to spoofing or replay
attacks.
Whenever a new Portal URL is received by end User Equipment, it
SHOULD discard the old URL and use the new one for future requests to
the API.
Whenever a new Portal URI is received by end User Equipment, it
SHOULD discard the old URI and use the new one for future requests to
the API.
Given that a user chooses to visit a Captive Portal URL, the URL
location SHOULD be securely provided to the user's device.  E.g., the
DHCPv6 AUTH option can sign this information.
Given that a user chooses to visit a Captive Portal URI, the URI
location SHOULD be securely provided to the user's device.  E.g., the
DHCPv6 AUTH option can sign this information.