Advancing the Registration Data Access Protocol (RDAP) to Internet Standard
status-change-rdap-to-internet-standard-01

If the documents were being opened up I would have some comments on
their content, but it's not really clear that there are any truly needed
changes.  It's also unclear that the topics are such that adding words
to the status-change document would help, either.

The main point that struck me is that 7480 and 7481 seem to give
qualitatively different pictures of the status of TLS usage for RDAP.
In RFC 7480 we see that "a client issues an HTTP (or HTTPS) query" and,
admittedly, that entities MUST support https, but no statement about
whether the actual *use* of HTTPS is recommended.  RFC 7481, on the
other hand, has the language about "HTTP over TLS MUST be used [...]
unless operational constraints make it impossible" that we would expect
from an Internet Standard (as well as unqualified requirements in
specific scenarios that require the protection TLS provides).

There is also a fair bit of text in RFC 7481 that is in some sense
"speculative", for example regarding the use of federated
authentication/authorization technologies and object-level cryptographic
protections on responses.  While this does not really reflect an "unused
protocol feature" that would need to be removed in order to advance to
Internet Standard, it is perhaps a little distracting when that's what
one's going for.

(I guess one thing that might be useful to add to the status-change
document is if there's any updates about the
implementation/specification status for such object-security or
federation techniques.)

If we were opening the documents I would ask for additional discussion
of the flaws and weaknesses of HTTP Basic authentication (and perhaps a
demotion of its recommended-level).

Two other comments on the text of RFC 7481, neither of which is likely
to require a text change, but still seem worth noting:

(Both quoted snippets appear in Section 3.2)

   This section describes security authentication mechanisms and the
   need for authorization policies to include them.  It describes
   requirements for the implementations of clients and servers but does
   not dictate the policies of server operators.  For example, a server
   operator with no policy regarding differentiated or tiered access to
   data will have no authorization mechanisms and will have no need for
   any type of authentication.  [...]

As a security practitioner I'm always wary of absolute statements like
this; for example, a server that does not have tiered access to data
might still benefit from authenticating clients for use in logging, and
post-facto inquiries into who had accessed certain data.

   Note that OAuth and OpenID do not consistently require data
   confidentiality services to protect interactions between providers
   and consumers.  HTTP over TLS [RFC2818] can be used as needed to
   provide protection against man-in-the-middle attacks.

The intent of this statement is perhaps a bit unclear.  It is a factual
statement that they do not always require as part of the protocol
confidentiality services, though it's arguably unclear whether that was
a wise decision or remains so.  Furthermore, I believe that the
generally accepted best practices for OAuth and OpenID have changed
since the time this text was written, with documents like
draft-ietf-oauth-security-topics providing carefully reasoned guidance
born of painful experience.