Internet-Draft CAPPORT API State Enhancement June 2024
Sawant Expires 28 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-sawant-capport-api-state-enhancement-00
Published:
Intended Status:
Informational
Expires:
Author:
P. Sawant
Apple Inc.

Captive Portal API State Structure Enhancement

Abstract

This document specifies a new key in Captive Portal API State data structure. The purpose of the new key is to allow clients to perform the client authentication without user interaction.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 December 2024.

Table of Contents

1. Introduction

As described in [RFC8908], the Captive Portal API data structure is specified in JavaScript Object Notation (JSON) [RFC8259]. Requests and responses for the Captive Portal API use the "application/captive+json" media type. The original specification specifies key "user-portal-url" to convey the web portal URL to the client. Although in most cases client devices are capable of presenting the web portal to the user, there are types of devices that are not built to support the user interaction with the web portal. This document specifies a new key that allows client to perform the authentication without user interaction.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. API State Structure Enhancement

Table 1 shows the new key that can be optionally included in the top-level of the JSON structure returned by the API server.

Table 1: Table 1
Key Type Description
authentication-server-url string It provides the URL of the Authentication Server that MUST be accessed over TLS. Authentication Server authenticates clients using the HTTP authentication framework specified in [RFC9110]. The server MUST NOT require user interaction on the client device. The client MUST have a credential to perform the authentication without user nteraction.

4. Security Considerations

This document recommends security considerations specified in Section 7 of [RFC8908].

5. Privacy Considerations

This document recommends privacy consideration specified in Section 7.1 of [RFC8908].

6. IANA Considerations

IANA is requested to add the new key specified in Table 1.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8908]
Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", RFC 8908, DOI 10.17487/RFC8908, , <https://www.rfc-editor.org/info/rfc8908>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.

Author's Address

Paresh Sawant
Apple Inc.