Field patterns, redux

Welcome to the fifth edition of the AIP newsletter, which is designed to keep you up to date about the AIP program, and particular proposals making their way through the system. (Our apologies for not publishing a newsletter in July.)

We have one new AIP this month, on sensitive fields. As always, the AIP newsletter kicks off what is effectively a "public comment" period: the AIP editors are happy with this proposal, but we want to ensure that you are too. Assuming feedback is sufficiently positive, we intend to formally approve these proposals on Friday, August 28, 2020.

AIPs under review

AIP-147: Sensitive fields

Sometimes APIs need to collect sensitive information such as private encryption keys meant to be stored by the underlying service but not intended to be read after writing due to the sensitive nature of the data.

Sensitive fields are fields that are stored by a service but, once set, not retrievable by the user, such as passwords or private keys. These are not particularly common in APIs, and often it is sufficient to set them as INPUT_ONLY (as described in AIP-203).

However, there is a challenge in situations where the service needs to provide some kind of indication that a value has been provided, or provide an obfuscated value that the original user ought to recognize. This AIP provides a standard for each of those situations.

A special thanks to Michael Bleigh for writing this AIP.

Summary: AIP-147 provides patterns for indicators around sensitive fields.

We are aiming to approve AIP-147 on August 28. If you have feedback, please leave a comment.

Recent updates

In addition to the new AIPs under review, we have added the following guidance to existing AIPs:

  • AIP-135: Add "get" guidance for soft delete. (#526)
  • AIP-140: Word segments in field names must not begin with a number. (#528)
  • AIP-151: Add guidance for parallel operations. (#535)
  • AIP-158: Clarify that page_size is always an opitonal field. (#537)