Smith,
> On Oct 23, 2019, at 1:43 PM, Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com> wrote:
> ...
> There are also some systems that use these "Job Accounting" data items, along with user authentication, as a way of limiting features that are available to users. For instance, we have customers that set up a system where certain users can only print in color from certain applications, and they base the processing alternatives on the values provided with the Job. Although I think we should be promoting Get-User-Printer-Attributes for this because it provides a superior user experience, this is another way that these data items are employed.
I think it is worth talking about this in the Job Accounting document, although I will note that currently Apple does not support Get-User-Printer-Attributes for some (unfortunately hard) architectural/security issues. Therefore, such policies need to be supported via a two-prong approach: Get-User-Printer-Attributes to provide the per-user capabilities, and Validate-Job/Create-Job/Print-Job/Print-URI enforcement/substitution for unsupported values.
> One other thing we may want to consider is adding an additional authentication identity or encryption key for the job accounting attributes that are sensitive.
This is where the Encrypted Jobs and Documents specification comes in, I think. In the interests of getting something deployed sooner, I would like to defer adding any discussion of this in the Job Accounting document until we have published that specification, which will likely mean a Job Accounting v1.1 or v2.0 BP in 2021...
> In some accounting systems, the job accounting information is not sent in-band with the Job by the driver chain to the printer, but is instead reported to a separate collection service by an agent on the client system. The security model is interesting because the accounting agent is running as an administrator user and authenticating using separate credentials. Basically, if the device itself is trusted to not be compromised, then the information is assumed to be trustable. This is a little different from the in-band job accounting communications topology we are articulating in the PWG, where the job accounting info is reported as job metadata and the job is submitted using a communications channel authorized using end-user authentication credentials, if the channel is authorized at all.
That is something we should mention in v1.0, with the goal of providing a direct IPP interface (probably in Encrypted Jobs and Documents) to replace these custom solutions.
(but let's make sure not to confuse an accounting solution that is bolted to the side of an OS printing system with a "native" IPP print service that provides accounting)
________________________
Michael Sweet