Michael,
Thank you for the information. I don’t mean to overly push a point, but making job-reprint-password an operations attribute just seems wrong and may contribute to the misunderstanding of its purpose. Job-password is inherently an operation attribute, and the references you provide point out that it is not returned in a response. So it is not clear why we cannot specify job-reprint-password as a job attribute that is never returned. That is, I do not understand why security information can be specially handled for operation attributes but not for job attributes. Is it perhaps some coding implementation issue?
And perhaps I was unclear on the remote reprint request subject, but my point was that if a user were to give reprint access to another user, he could provide the job ID or job UID as well as the password. If a remote reprint capability were desired, I suggest that an operation could be defined to use that information to access the appropriate job and allow remote reprint.
Thanks, Bill Wagner
From: Michael Sweet
Sent: Tuesday, July 24, 2018 11:57 PM
To: William A Wagner
Cc: Kennedy, Smith (Wireless & Standards Architec); PWG IPP WG Reflector
Subject: Re: [IPP] Another updated stable draft of IPP ReprintPasswordpostedfor review
Bill,
On Jul. 24, 2018, at 2:32 PM, wamwagner at comcast.net wrote:
Michael,
Thank you for your response. Perhaps I misunderstand, but in regard to your first comment, “Security attributes are not exposed as Job Description/Status/Template attributes …”, do you mean expose via a Het-Jobs or Get-Job-Attributes request? But in regard to this request, RFC 8011 says in with regard to both opertions:
The IPP object ignores (does not respond with) any requested attribute or value which is not supported or which is restricted by the security policy in force, including whether the requesting user is the user that submitted the job (job originating user) or not (see section 8).
Are Job Description attributes exposed in some other way?
Generally speaking, ALL Job Description attributes are available to the Job Owner and any authorized operators or administrators. Because IPP has never defined a formal ACL framework or (until my Privacy Attributes registration) a way to specify which attributes contain sensitive information that would be subject to the RFC 8011 "rules", we have explicitly specified that security credentials are not part of the public Job object attributes (even to the Job Owner), that they are passed as operation attributes and not Job Template attributes, and that they are not copied to Job Description or Job Status attributes. See:
- PWG 5100.11 (JPS2): job-password and job-password-encryption
- PWG 5100.13 (JPS3): document-password
- PWG 5100.17 (SCAN): destination-accesses
- PWG 5100.18 (INFRA): document-access
With respect to remote reprint request, if a user is provided with the password, could he not also be provided with the name and/or location of the job? Might a Get-Jobs operation be adequate?
Typically job-name and job-printer-uri are treated as sensitive information and thus is not visible to ordinary users unless they are the Job Owner. The only attributes that RFC 8011 requires Get-Jobs to return are "job-id" and "job-uri".
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180725/9c37f302/attachment.html>