Change:
As discussed in , define an IANA registry for extending JSON keys use for Captive Portal API.
NAME NAME thanks for the comments. Please take another pass!
Should we define an IANA registry for adding new keys?
Yes, yes we should.
and i already commented in the PR, but if possible it would be beneficial to have some distinction between IETF or a relevant organization (like WFA, WBA) requested keys vs from some individual organization
Would we want to suggest having a nested dictionary format for organization-specific extensions? Like "wba" as a key to a dictionary; or a sub-dictionary indicating that there are WISPr-related settings to be aware of?
i think it would be a good idea. We have seen WBA start to take active interest in the documents. Also there's work happening in WFA that could benefit from having an extension point
RFC 6648 might suggest otherwise. If there are things that a group wants to add that are truly unique to that group, this is probably fine.
Yes, I think that more than having per-group keys (with almost certain overlap), I'd imagine that compatibility with certain technologies would be handled via these sub-dictionaries, such as what I mentioned for WISPr. Not sure how critical mentioning this is in the document though.
Can we call this one done?
I'm assuming we will go down the path of defining an IANA registry with access technology specific extension ?
The description in "Captive Portal API Keys Registry" gives some guidance for prefixes, etc. I assume the experts once designated can work with WFA/WBA to define proper entries.

Discussion:
captive=true), it can still be allowed enough access for it to perform server authentication server-auth. <del> "user-portal-url" (required, string): provides the URL of a web </del> <ins> "user-portal-url" (optional, string): provides the URL of a web </ins> portal with which a user can interact. "vendor-info-url" (optional, string): provides the URL of a webpage or site on which the operator of the network has <del> information that it wishes to share with the user (e.g. store </del> <ins> information that it wishes to share with the user (e.g., store </ins> info, maps, flight status, or entertainment). "expire-date" (optional, string formatted as RFC3339 datetime):

portal systems might not count traffic to whitelisted servers, such as the API server, but clients cannot rely on such behavior. <ins> The valid JSON keys can be extended by adding entries to the Captive Portal API Keys Registry iana-section.  If a client receives a key that it does not recognize, it MUST ignore the key and any associated values.  All keys other than the ones defined in this document as "required" will be considered optional. </ins> 4.3. A client connected to a captive network upon discovering the URI of

6. <ins> IANA is requested to create a registration for an "application/ captive+json" media type (iana-json) and a registry for fields in that format (iana-field-reg). 6.1. </ins> This document registers the media type for Captive Portal API JSON text, "application/captive+json".

IETF <ins> 6.2. IANA is asked to create and maintain a new registry called "Captive Portal API Keys", which will reserve JSON keys for use in Captive Portal API data structures.  The initial contents of this registry are provided in json-keys. Each entry in the registry contains the following fields: The JSON key being registered, in string format. The type of the JSON value to be stored, as one of the value types defined in RFC8259. A brief description explaining the meaning of the value, how it might be used, and/or how it should be interpreted by clients. New assignments for Captive Portal API Keys Registry will be administered by IANA through Expert Review RFC8126.  The Designated Expert is expected to validate the existence of documentation describing new keys in a permanent publicly available specification. The expert is expected to validate that new keys have a clear meaning and do not create unnecessary confusion or overlap with existing keys.  Keys that are specific to non-generic use cases, particularly ones that are not specified as part of an IETF document, are encouraged to use a domain-specific prefix. </ins> 7. This work in this document was started by Mark Donnelly and Margaret