Thanks for this. We should review this proposal in detail, probably at the August F2F.
Some initial impressions:
1. One of the items in the original feedback at the last F2F was:
Shouldn‘t authenticated user determine which job-account-id values are allowed?
⁃ i.e. user ‘JohnDoe’ is allowed to use three accounts: "project1", "project2", and "project3"
⁃ Printer can reject jobs when the authenticated user is not allowed to use the job-account-id specified
It still isn't clear why authenticating the user at the HTTP level is insufficient - perhaps a use case in the slide deck will better explain this?
2. A client-supplied "salt" does not prevent replay attacks, and in fact would require the server to have the original plain text password so that it can generate a hash of the password+salt. *If* the intent is to reproduce something like HTTP Digest authentication, I highly recommend reading and using RFC 7616 (the current published HTTP Digest spec) in the design of this extension proposal. HTTP Digest uses client and server supplied nonces to protect against replay attacks and provide a (small) level of assurance as to the authenticity of each party.
3. We need to document how a client would discover that the printer requires job-account-password - both passively (Get-Printer-Attributes) and actively (Create-Job returns something to tell the client to authenticate outside of HTTP).
> On Jun 30, 2016, at 6:15 PM, Yardumian, Rick <RYardumian at ciis.canon.com> wrote:
>> At the last face to face meeting, Canon’s proposal to add a job-account-password was rejected due to its use of a clear text password and other issues. Canon has updated their proposal in the attached PowerPoint slides to correct the issues brought up in the face to face meeting. Please review the attached proposal and reply with your comments.
>> Thank you,
> Rick Yardumian
> <[Canon-OIP] PWG proposal(job account password)-20160630.pptx>_______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...