This proposed standards draft specifies an extension to the JSON Meta Application Protocol (JMAP).  Specifically this draft defines an extension for creating, identifying, and retrieving "blobs" of data without the need of utilizing separate roundtrips.

The security considerations section does exist and refers to various ways to mitigate against attacks related to unsupported data types, unauthorized access control, blob existence leaks, mismatch between data type and data, and the fragmentation of data to bypass scanner checks.  I concur with the set of possible attacks on this extension, though I do have one question on this sentence:

    The server SHOULD NOT reject data on the grounds that it is not a valid specimen of the stated type.

Is there ever a case that one implementation accepts the data that does not match the specified type and then another implementation assumes that the data is that of the specified type?  If this is the case then this could lead to vulnerabilities while parsing said data.

The security consideration section should also initially state something similar to that of RFC 8621:
   All security considerations of JMAP [RFC8620] apply to this
   specification.  Additional considerations specific to the data types
   and functionality introduced by this document are described [below].

General Comments:

Thank you for the variety of examples, though it would have been easier to read them if the request and response were in sequence rather than trying to remember which response went to which request or by scrolling up and down a few pages to correlate the two.

I'm not for sure I understand the purpose of the Blob/get:properties:digest function.  Won't the endpoints be able to do this over the datafield for themselves?

Editorial Comments:

s/of of/of/
s/supportedDigestAlgorithms/supportedDigestAlgorithms:/
s/in future/in the future/