Trust.txt: Why another random .txt when we've got WebFinger and well-known URIs?

Scott Yates, in his statement of candidacy
<https://lists.w3.org/Archives/Public/public-credibility/2021Aug/0000.html>,
includes a description of the trust.txt file
<https://journallist.net/reference-document-for-trust-txt-specifications>.

Please explain why it makes sense to introduce yet-another .txt file (in
addition to robots.txt and ads.txt) when we have established procedures to
allow those who control URIs to make statements supported by that control.
For instance, RFC 5785 <https://datatracker.ietf.org/doc/html/rfc5785> defines
the "/.well-known/" path prefix for "well-known locations" which are
accessed via URIs. It seems to me that if one were to publish a trust.txt
file, then it should be at the location "/.well-known/trust.txt" That does
not seem to be the current proposal. Why are existing standards not being
followed?

It also seems to me that the proposed file format is an unnecessary
departure from existing standards such as RFC 7033
<https://datatracker.ietf.org/doc/html/rfc7033>, which defined WebFinger, a
mechanism that could be easily used to carry the data which the proponents
of trust.txt seek to make available. To make WebFinger do what trust.txt
intends, it would be only necessary to register a few new JSON
Resource Descriptors (JRDs), properties, or link-relations (i.e. belong-to,
control, social, member, etc.). This sort of extension is provided for in
the definition of RFC 7033 and in RFC 5988
<https://datatracker.ietf.org/doc/html/rfc5988>, which defines "Web
Linking" mechanisms. Note: The existing set of defined link-relations can
be found in the IANA maintained link-relations registry
<https://www.iana.org/assignments/link-relations/link-relations.xhtml>.

While there will be a never-ending need to add support for new kinds of
standardized statements, discoverable in well-known locations, I think we
should be careful to ensure that new kinds of statements make use of
existing standards rather than define entirely new mechanisms. I can't see
anything in the trust.txt specification that actually requires a unique,
non-standard approach that is not already supported by the various
standards referenced above.

bob wyman