[This documents behavior that goes back to RFC 2566 - Internet Printing Protocol/1.0: Model and Semantics]
The Get-Printer-Attributes operation is unique in that it does not support authentication of any kind. The primary reason for this is that it is needed for discovering the supported URIs, security, and authentication methods for the Printer via the "printer-uri-supported", "printer-xri-supported", "uri-authentication-supported", and "uri-security-supported" attributes. A secondary reason is that the corresponding SNMP Printer MIB elements are likewise available without authentication.
Unfortunately, when we updated RFC 2911 (what became RFC 8011 and STD 92) we forgot to explicit call this out, instead relying on the historical omission of any "access rights" paragraph in the definition of the Get-Printer-Attributes operation. All other operations in RFC 2566/2911/8011 provide (directly or indirectly) a statement about the users that are allowed to send the operation, whose identity comes from the "most authenticated" source. While the Get-Printer-Attributes description is silent on this, every IPP implementation since IPP/1.0 has allowed Get-Printer-Attributes requests without authentication in order to allow Clients to discover Printers, and the major IPP-based driverless printing standards (AirPrint, IPP Everywhere, Mopria, Wi-Fi Direct Printing) all depend on it.
Several years ago we defined a new Get-User-Printer-Attributes operation that performs the same query as Get-Printer-Attributes but that explicitly allows authentication in order to filter Printer capabilities based on the most authenticated user identity and whatever policy is in effect on the Printer.
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220113/3020d758/attachment.sig>