Subject: Re: [IPP] Another updated stable draft of IPP Reprint Password postedfor review

From: <[email-masked]>
Date: Mon, 23 Jul 2018 14:53:07 -0400

Greetings,
Some comments on this draft, largely prompted by observations during the last IPP conference.  Sorry about the wordiness.

Comments made based on my understanding (or misunderstanding) of this proposed element, as it has evolved. 

1. The function of this password is to control access to a retained job. As evolved, it has been maintained that access is only for printing the job and access (as far as IPP is concerned) is only from a console on which the retained job is stored. [There might, one would assume, be non-IPP mechanisms, such as a remote console, or out-of-band communications whereby a user could request access to a job stored elsewhere,  but once a job is tagged with a Job Reprint Password, access to the stored by someone not normally having access should require submission of the Job Reprint Password defined when the job was created.]
2. I would argue that this should be a Job Description attribute rather than an Operation attribute, because it stays with the Job and is really an attribute of the job rather than any IPP operation. I also suggest that this attribute should not in itself cause Job Save, since IPP already has the “job-save-disposition” (collection) Job Template attribute and there are other implementation dependent job retention factors. This would also preclude the automatic saving of copied jobs.
3. It may be desirable to make clear the distinction between Job Password, Document Password and Job Reprint Password in this specification. I would suggest a simple statement of the purpose of these three passwords.
a. document-password [PWG5100.13] is an operation attribute provided with a Print-Job, Print-URI, Send-Document, or Send-URI operation to allow access to the document content, typically to "unlock" a previously password-protected PDF or OpenXPS document. The value supplied is  retained by the Printer as long as the corresponding Document is retained.
b. job-password [PWG5100.11] is an operation attribute optionally provided with a Print-Job, Print-URI, or Create-Job operation to cause a submitted job to be held in a 'pending-held' state until the password value is submitted to the printing device. The method in which the password is entered and validated at the Printer is implementation dependent. The job-password value is not saved with the Job.
c. job-reprint-password is [a Job Description or an operation attribute] optionally provided with a Print-Job, Print-URI, or Create-Job operation that (if accepted by the Printer), causes the submitted job-reprint-password to be saved with the retained Job. It does not affect the processing of the job in any other way. Although IPP does allow a retained job to be reprinted via Resubmit-Job, this capability is only available if the user performing this operation is the job owner or an operator or administrator of the Printer object. However, if outside of IPP, the Printer provides a user with the ability to reprint retained jobs, and the desired Job has been tagged with a job-reprint-password, the user must supply that password to get access to the job for reprint (or any other purpose?)
4. As far as I can tell, reprinting a job is not a defined IPP operation nor is it clear to me why giving access to an IPP retained Job by some means other than IPP can restrict how that job is used. At any rate, from the discussion, the identified job (which is somehow selected by the user) is not itself affected in any way other than by being copied and, since "most operation attributes do not persist beyond the life of the operation" that new job is printed (whatever than might involve) following operation attributes defined by the user when he has, by whatever means outside of IPP, initiated "reprint" of a selected IPP job. 
5. The original use case of allowing remote reprint was eliminated, although if the purpose of Job Reprint Password is solely to allow access to a retained IPP Job, (rather than to act as a Job Password for a reprinted Job), it would seem that remote reprint is a useful feature. Would it be that cumbersome to change an operation such as ResubmitJob to bestow job ownership  (of the copied Job) to a user having the password? 
Thanks, Bill Wagner

From: Kennedy, Smith (Wireless & Standards Architec)
Sent: Wednesday, June 20, 2018 2:06 PM
To: PWG IPP WG Reflector
Subject: [IPP] Another updated stable draft of IPP Reprint Password postedfor review

Greetings,

I have posted another update to IPP Reprint Password. It is available here:

   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippreprintpwd-20180620.pdf
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippreprintpwd-20180620.odt
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippreprintpwd-20180620-rev.pdf
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippreprintpwd-20180620-rev.odt

Changes in this revision include:
• Added a figure to section 3, and moved the section 4 preamble text added in the 2018-06-19 revision to be in section 3

Cheers!

Smith

/**
   Smith Kennedy
   Wireless & Standards Architect - IPG-PPS
   Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
   Chair, IEEE ISTO Printer Working Group
   HP Inc.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 23 Jul 2018 19:27:04 -0400

Bill,

Some responses to your feedback are inline below...

> On Jul. 23, 2018, at 2:53 PM, [email-masked] wrote:
> ...
> I would argue that this should be a Job Description attribute rather than an Operation attribute, because it stays with the Job and is really an attribute of the job rather than any IPP operation. I also suggest that this attribute should not in itself cause Job Save, since IPP already has the “job-save-disposition” (collection) Job Template attribute and there are other implementation dependent job retention factors. This would also preclude the automatic saving of copied jobs.

Security attributes are not exposed as Job Description/Status/Template attributes as that will expose the very credentials that would be required to reprint the job from the console.

As for not causing a Job Save, JPS2 already has an implicit/lightweight local save that happens when you use the proof-print Job Template attribute - the semantics of Proof Print are that "I am printing a draft/proof copy of this job and intend to print more copies if the proof copy is good."  Similarly, specifying a "job-reprint-password" operation attribute specifies that you intend to print more copies of the job at a later time.  Perhaps using "Job Save" is the sticking point here - perhaps just saying "Job Retention" is enough?

> It may be desirable to make clear the distinction between Job Password, Document Password and Job Reprint Password in this specification. I would suggest a simple statement of the purpose of these three passwords.
> document-password [PWG5100.13 <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf>] is an operation attribute provided with a Print-Job, Print-URI, Send-Document, or Send-URI operation to allow access to the document content, typically to "unlock" a previously password-protected PDF or OpenXPS document. The value supplied is  retained by the Printer as long as the corresponding Document is retained.
> job-password [PWG5100.11 <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext10-20101030-5100.11.pdf>] is an operation attribute optionally provided with a Print-Job, Print-URI, or Create-Job operation to cause a submitted job to be held in a 'pending-held' state until the password value is submitted to the printing device. The method in which the password is entered and validated at the Printer is implementation dependent. The job-password value is not saved with the Job.
> job-reprint-password is [a Job Description or an operation attribute] optionally provided with a Print-Job, Print-URI, or Create-Job operation that (if accepted by the Printer), causes the submitted job-reprint-password to be saved with the retained Job. It does not affect the processing of the job in any other way. Although IPP does allow a retained job to be reprinted via Resubmit-Job, this capability is only available if the user performing this operation is the job owner or an operator or administrator of the Printer object. However, if outside of IPP, the Printer provides a user with the ability to reprint retained jobs, and the desired Job has been tagged with a job-reprint-password, the user must supply that password to get access to the job for reprint (or any other purpose?)

Just for reprint.  And I like this as a summary of the differences between the three attributes.

> As far as I can tell, reprinting a job is not a defined IPP operation nor is it clear to me why giving access to an IPP retained Job by some means other than IPP can restrict how that job is used. At any rate, from the discussion, the identified job (which is somehow selected by the user) is not itself affected in any way other than by being copied and, since "most operation attributes do not persist beyond the life of the operation" that new job is printed (whatever than might involve) following operation attributes defined by the user when he has, by whatever means outside of IPP, initiated "reprint" of a selected IPP job. 

We have Restart-Job (deprecated), Reprint-Job (deprecated), and Resubmit-Job (the recommended replacement for the previous two).  All of these have the typical "Job owner, operator, or administrator" for the access rights (policy), but when reprinting from the console there is often no way to do traditional authentication (thus the invention of PIN printing, etc.)

> The original use case of allowing remote reprint was eliminated, although if the purpose of Job Reprint Password is solely to allow access to a retained IPP Job, (rather than to act as a Job Password for a reprinted Job), it would seem that remote reprint is a useful feature. Would it be that cumbersome to change an operation such as ResubmitJob to bestow job ownership  (of the copied Job) to a user having the password? 
We could definitely add that in, but how would a user that is not the job owner, an operator, or an administrator discover a job that could be reprinted?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: <[email-masked]>
Date: Tue, 24 Jul 2018 14:32:13 -0400

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?

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?
Thanks, 
Bill Wagner

From: Michael Sweet
Sent: Monday, July 23, 2018 7:27 PM
To: William A Wagner
Cc: Kennedy, Smith (Wireless & Standards Architec); PWG IPP WG Reflector
Subject: Re: [IPP] Another updated stable draft of IPP Reprint Passwordpostedfor review

Bill,

On Jul. 23, 2018, at 2:53 PM, [email-masked] wrote:
...
1. I would argue that this should be a Job Description attribute rather than an Operation attribute, because it stays with the Job and is really an attribute of the job rather than any IPP operation. I also suggest that this attribute should not in itself cause Job Save, since IPP already has the “job-save-disposition” (collection) Job Template attribute and there are other implementation dependent job retention factors. This would also preclude the automatic saving of copied jobs.

1. It may be desirable to make clear the distinction between Job Password, Document Password and Job Reprint Password in this specification. I would suggest a simple statement of the purpose of these three passwords.
a. document-password [PWG5100.13] is an operation attribute provided with a Print-Job, Print-URI, Send-Document, or Send-URI operation to allow access to the document content, typically to "unlock" a previously password-protected PDF or OpenXPS document. The value supplied is  retained by the Printer as long as the corresponding Document is retained.
b. job-password [PWG5100.11] is an operation attribute optionally provided with a Print-Job, Print-URI, or Create-Job operation to cause a submitted job to be held in a 'pending-held' state until the password value is submitted to the printing device. The method in which the password is entered and validated at the Printer is implementation dependent. The job-password value is not saved with the Job.
c. job-reprint-password is [a Job Description or an operation attribute] optionally provided with a Print-Job, Print-URI, or Create-Job operation that (if accepted by the Printer), causes the submitted job-reprint-password to be saved with the retained Job. It does not affect the processing of the job in any other way. Although IPP does allow a retained job to be reprinted via Resubmit-Job, this capability is only available if the user performing this operation is the job owner or an operator or administrator of the Printer object. However, if outside of IPP, the Printer provides a user with the ability to reprint retained jobs, and the desired Job has been tagged with a job-reprint-password, the user must supply that password to get access to the job for reprint (or any other purpose?)

---

From: Michael Sweet <[email-masked]>
Date: Tue, 24 Jul 2018 23:56:55 -0400

Bill,

> On Jul. 24, 2018, at 2:32 PM, [email-masked] wrote:
> 
> Michael,
>          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 <https://tools.ietf.org/html/rfc2911#section-8>).  
> 

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".

---

From: <[email-masked]>
Date: Wed, 25 Jul 2018 18:50:56 -0400

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,

Michael,

---

From: Michael Sweet <[email-masked]>
Date: Wed, 25 Jul 2018 20:52:32 -0400

Bill,

> On Jul. 25, 2018, at 6:50 PM, [email-masked] wrote:
> 
> Michael,

If you define an attribute to be a Job Description, Job Template, or Job Status attribute, you are declaring that the attribute is something that can be returned by the Get-Job-Attributes and Get-Jobs operations (per the semantics of those operations).  But an operation attribute has to have explicitly defined semantics (like we have for requesting-user-name getting copied to job-originating-user-name) before it becomes exposed by those operations.

> 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…

But again the semantics of the Resubmit-Job operation only allows the Job Owner, administrators, and operators to reprint just any job.  We'd need to amend the semantics to allow other users to do it...