Daniel,
The recommended practice for Clients is to send an empty Validate-Job request (just printer-uri and requesting-user-name) to verify the selection of the Printer by the User - this verifies access to the Printer and allows the Printer to require authentication. If authenticated, subsequent requests to the Printer will include the negotiated HTTP credentials, per RFC 2616/2617.
When the Client next sends a Get-Printer-Attributes request with the existing credentials, the Printer MAY return a filtered list of Job Template attributes and values that the Client/User is authorized to use - the printer-get-attributes-supported attribute tells the Client which attributes are used for filtering the returned values. The presence of "requesting-user-name" indicates that the Printer will use the most-authenticated user name, per the usual RFC 2911 usage of requesting-user-name for requests.
I would be happy to add a paragraph specifically about this to the Transaction-Based Printing Extensions specification - it would be an excellent editorial comment as part of your vote for the PWG Formal Vote of the spec that was recently approved by the Steering Committee,
We should also make the consequences of the HTTP security model clear in Smith's IPP Implementers Guide 2.0 document as well - a User Agent re-uses the Authentication header in subsequent requests to the same origin for the duration of the User Agent's "session", e.g., the life of a web browser process, the life of a print job submission, etc.
On Oct 1, 2013, at 1:14 AM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:
> Current day printer driver user interfaces esp. those for mobile clients need a UI that displays only those capabilities that a user has before submitting a job (or grey out those features that are not available to certain users who do not have the authorization / privileges / rights to use those features). We discussed the merits of using Validate-Job.
>> The problem with Validate-Job as we discussed in one of our earlier IPP meetings is this (using a scenario): If there is a request for simplex printing in the Validate-Job request it means the user interface already allowed the user to select simplex printing. The desired scenario is that the UI only present the user (at the client interface) with the capabilities they have. So I don't know that Validate-Job is useable to check for user capabilities (that the client uses first to determine capabilities).
>> Using the current definition of Validate-Job, one needs to perform job programming and validate it by sending a set of attributes regarding how the user wants their job to be programmed or processed. This is not helpful for an UI (esp. mobile clients) that want to display to the user only those capabilities that the user is authorized to use (which is a sub set of all the Printer capabilities or a super set of a guest user whose capabilities are returned by a Get-Printer-Attributes request).
>> The request is to add a new operation “Get-User-Capabilities” wherein one submits user’s credentials along with the operation request so that the operation response contains a “job-authorization-uri” which in turn can be used to obtain those capabilities of the Printer that the user has authorization to use or the operation response just contains the user’s capabilities for the Printer.
>> In the former case, we need to make the following one small change to the IPP Transaction Based Printing spec.
>> Section 6.1.2 “job-authorization-uri (uri)” states:
>> The "job-authorization-uri" operation attribute specifies an implementation-specific URI representing an authorization or reservation code for a print job creation request. It is returned by the Validate-Job operation (section 7.2) and supplied in the Create-Job, Print-Job, and Print-URI operations (section 7.1).
>> This should be extended as:
>> The “job-authorization-uri” would be returned by the new “Get-User-Capabilities” operation request. The authorization or reservation code represented by the “job-authorization-uri” could be used by Get-Printer-Attributes request to return the authenticated user capabilities.
>> The reason to make this change is because the unauthorized Get-Printer-Attributes returns a limited set of capabilities (e.g., the set of capabilities of a guest user) on a system that has authentication enabled.
>> If it is not acceptable to extend the semantics of “job-authorization-uri”, could we create a “user-authorization-uri” that could be used to get the user’s capabilities?
>> Thanks,
> Daniel.
>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131001/59b5d799/attachment.html>