Subject: [IPP] "Get-User-Supported-Values" operation?

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 13 Jan 2017 06:32:48 +0000

Greetings,

I remember back when I was doing the IPP Implementor's Guide v2 we had discussed a "Get-User-Supported-Values" operation, that would provide the list of supported attributes for a given user. Now that we are a few years on from that, and in the middle of System Service, what is the current IPP WG thinking about where such an operation ought to be defined?

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - 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: Sat, 14 Jan 2017 11:11:14 -0500

Smith,

The thinking before was that the proposer would put together a white paper so that we could formally discuss things and propose it as new work for the IPP WG.  Given the scope, this won't be a huge undertaking (probably on the order of 10 pages, including boilerplate), but it is a necessary step so that everyone is on the same page.

FWIW, I do not think this should be added to IPP System Service since this operation is targeted at the job services (Print, FaxOut, Scan) and *not* for the System service.

> On Jan 13, 2017, at 1:32 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Ira McDonald <[email-masked]>
Date: Sat, 14 Jan 2017 11:45:13 -0500

Hi Smith,

I agree with Mike that this operation should not be added to IPP System
Service.

I question the need for this operation.

An IPP job service implementation can filter a Get-Printer-Attributes
response already based on authenticated user identity.

What new functionality would this putative operation add to IPP?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sat, Jan 14, 2017 at 11:11 AM, Michael Sweet <[email-masked]> wrote:

> Smith,
>
> The thinking before was that the proposer would put together a white paper
> so that we could formally discuss things and propose it as new work for the
> IPP WG.  Given the scope, this won't be a huge undertaking (probably on the
> order of 10 pages, including boilerplate), but it is a necessary step so
> that everyone is on the same page.
>
> FWIW, I do not think this should be added to IPP System Service since this
> operation is targeted at the job services (Print, FaxOut, Scan) and *not*
> for the System service.
>
>
> > I remember back when I was doing the IPP Implementor's Guide v2 we had
> discussed a "Get-User-Supported-Values" operation, that would provide the
> list of supported attributes for a given user. Now that we are a few years
> on from that, and in the middle of System Service, what is the current IPP
> WG thinking about where such an operation ought to be defined?
> >
> > Smith
> >
> > /**
> >    Smith Kennedy

---

From: Michael Sweet <[email-masked]>
Date: Sat, 14 Jan 2017 13:45:33 -0500

Ira,

> On Jan 14, 2017, at 11:45 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Smith,
> 

>From a practical perspective, Get-Printer-Attributes is never authenticated because clients do not support that usage. So no, we can't just use Get-Printer-Attributes...

Right now clients need to use Validate-Job (which *is* authenticated for printers that do authentication of print jobs) in order to validate the choices a user has made.

> What new functionality would this putative operation add to IPP?

It would be defined as an authenticated version of Get-Printer-Attributes that explicitly filters the values based on the authenticated identity of the requestor.

---

From: Ira McDonald <[email-masked]>
Date: Sat, 14 Jan 2017 15:51:31 -0500

Hi Mike,

Thanks for those clarifications.

I suggest the proposed new operation be named "Get-User-Printer-Attributes"
to show the authenticated User dependence and the otherwise similarity to
the classic "Get-Printer-Attributes" operation.

I agree that a brief whitepaper is appropriate.

I have strong reservations about adding a new operation (as opposed to some
attributes) simply via IPP WG approval for IANA registration.  We should
talk
more about where this operation might be published.

Cheers,
- Ira

On Sat, Jan 14, 2017 at 1:45 PM, Michael Sweet <[email-masked]> wrote:

> From a practical perspective, Get-Printer-Attributes is never
> authenticated because clients do not support that usage. So no, we can't
> just use Get-Printer-Attributes...
>
> Right now clients need to use Validate-Job (which *is* authenticated for
> printers that do authentication of print jobs) in order to validate the
> choices a user has made.
>
> It would be defined as an authenticated version of Get-Printer-Attributes
> that explicitly filters the values based on the authenticated identity of
> the requestor.
>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 15 Jan 2017 09:08:36 -0500

Ira,

The registration policy for operations is Expert Review, so a full specification is not technically required. That said, we (the designated experts) and the IPP workgroup can require sufficient clarity in the definition of the operation before such a registration is approved, or to require a spec of the scope of the registration is (in the opinion of the WG or designated experts) too broad for a simple registration.

In the case of this operation, we simply (IMHO) do not have enough information to decide.

Sent from my iPad

> On Jan 14, 2017, at 3:51 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 
> attributes) simply via IPP WG approval for IANA registration.  We should talk

---

From: Ira McDonald <[email-masked]>
Date: Sun, 15 Jan 2017 10:36:07 -0500

Hi Mike and Smith,

I suggest that the parameters and attributes of such an operation

are exactly the same as Get-Printer-Attributes, except that the User
identity MUST be authenticated and MUST be authorized (via some
out-of-band manner) to perform the new operation.

It might be appropriate to abandon the "limit" and friends and also
to say that you can't read "media-col-database" with this operation.
It might also be appropriate to abandon "requested-attributes" and
just return all the simple attributes and "xxx-supported" attributes.

Smith - please think about the use case(s) and propose by email
some more details for discussion as a next step.

Cheers,
- Ira

On Sun, Jan 15, 2017 at 9:08 AM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> The registration policy for operations is Expert Review, so a full
> specification is not technically required. That said, we (the designated
> experts) and the IPP workgroup can require sufficient clarity in the
> definition of the operation before such a registration is approved, or to
> require a spec of the scope of the registration is (in the opinion of the
> WG or designated experts) too broad for a simple registration.
>
> <(734)%20944-0094>
> <(906)%20494-2434>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 15 Jan 2017 20:22:53 -0500

Ira,

The point of the operation is for a Client UI to be able to show the attributes and values the user is allowed to select, which necessarily includes things like "media-col-database".  The user may be identified through requesting-user-name, authenticated user name, source IP, client certificate, etc., with the details of any filtering being an implementation detail.

Defining "Get-User-Supported-Values" as analogous to "Get-Printer-Attributes" except that the operation filters the attributes and values based on the (most authenticated) user identity keeps things relatively simple and avoids future "oh shit" moments when we realize we added too many restrictions.  And for conformance we'll want to require Client and Printer support for authentication but not require a Printer to use authentication, i.e., an allowed configuration is to just rely on the requesting-user-name, source IP, etc.

Ideally, a Printer should not advertise the new operation unless it will be performing some sort of filtering - that allows for simple client-side optimizations when printer capabilities are not limited by user or other Client metadata.

> On Jan 15, 2017, at 10:36 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike and Smith,
>

---

From: Ira McDonald <[email-masked]>
Date: Sun, 15 Jan 2017 20:45:43 -0500

Hi Mike,

You are suggesting this new Get-User-Printer-Attributes operation
does NOT require authentication and authorization of the Client?

If that's right, what value does this operation offer over the classic
Get-Printer-Attributes (with perhaps an "ipp-features-supported"
tag that says it supports User-based filtering)?

My reading of original RFC 2911 was that *any* operation could do
filtering based on the requesting user (i.e., Get-Jobs).

Confused,
- Ira

On Sun, Jan 15, 2017 at 8:22 PM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> The point of the operation is for a Client UI to be able to show the
> attributes and values the user is allowed to select, which necessarily
> includes things like "media-col-database".  The user may be identified
> through requesting-user-name, authenticated user name, source IP, client
> certificate, etc., with the details of any filtering being an
> implementation detail.
>
> Defining "Get-User-Supported-Values" as analogous to
> "Get-Printer-Attributes" except that the operation filters the attributes
> and values based on the (most authenticated) user identity keeps things
> relatively simple and avoids future "oh shit" moments when we realize we
> added too many restrictions.  And for conformance we'll want to require
> Client and Printer support for authentication but not require a Printer to
> use authentication, i.e., an allowed configuration is to just rely on the
> requesting-user-name, source IP, etc.
>
> Ideally, a Printer should not advertise the new operation unless it will
> be performing some sort of filtering - that allows for simple client-side
> optimizations when printer capabilities are not limited by user or other
> Client metadata.
>
>
> >> Right now clients need to use Validate-Job (which *is* authenticated
> for printers that do authentication of print jobs) in order to validate the
> choices a user has made.
> >>
> >> It would be defined as an authenticated version of
> Get-Printer-Attributes that explicitly filters the values based on the
> authenticated identity of the requestor.
> >>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 15 Jan 2017 22:49:04 -0500

Ira,

> On Jan 15, 2017, at 8:45 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 

No, I am suggesting that this new operation *may* not require Client authentication, depending on the configuration of the Printer, just as Cancel-Job, Cancel-All-Jobs, Cancel-My-Jobs, Create-Job, Get-Job-Attributes, Get-Jobs, Print-Job, Print-URI, Send-Document, Send-URI, and Validate-Job do.

FWIW, Get-Printer-Attributes is basically the only operation in IPP/1.1 (RFC 2911/8011) that does not say anything about authentication, the most authenticated identity, authorization rights, or filtering of attributes or values based on the most authenticated identity.  And that makes it impossible to add authentication requirements without breaking a lot of (read: all) Clients.

> tag that says it supports User-based filtering)?

It makes it consistent with the Job operations.

> filtering based on the requesting user (i.e., Get-Jobs).

No, there is discussion of authentication and the most authenticated user/identity, but specific requirements and filtering are discussed in the description of each operation.  In particular, Get-Jobs and Get-Job-Attributes talk about filtering based on security policy, while Get-Printer-Attributes only talks about filtering based on document format (and basically says everyone gets to see the same information).

This is arguably a bug in the original IPP specs, but there is nothing we can do to fix Get-Printer-Attributes now.
(but there are advantages to having a public/guest "get" operation for discovering what a Printer will require, e.g., "uri-authentication-supported" values...)

---

From: Ira McDonald <[email-masked]>
Date: Thu, 26 Jan 2017 13:14:52 -0500

Hi,

Smith plans to bring a whitepaper and/or slides on this new operation
(tentatively to be named Get-User-Printer-Attributes for clarity) to the
PWG F2F meeting in February.

On reflection, I suggest that perhaps we *should* add this operation
to IPP System Service to enhance IPP Client interworking with IPP
Printers (job services).

Mike has convinced me that the operation should look just like the
existing Get-Printer-Attributes operation (input/output attributes),
but allow the Printer (if so configured) to authenticate the Client's
requesting user identity and always require filtering of the response
based on the most authenticated requesting user identity.

Cheers,
- Ira

On Sun, Jan 15, 2017 at 10:49 PM, Michael Sweet <[email-masked]> wrote:

> No, I am suggesting that this new operation *may* not require Client
> authentication, depending on the configuration of the Printer, just as
> Cancel-Job, Cancel-All-Jobs, Cancel-My-Jobs, Create-Job,
> Get-Job-Attributes, Get-Jobs, Print-Job, Print-URI, Send-Document,
> Send-URI, and Validate-Job do.
>
> FWIW, Get-Printer-Attributes is basically the only operation in IPP/1.1
> (RFC 2911/8011) that does not say anything about authentication, the most
> authenticated identity, authorization rights, or filtering of attributes or
> values based on the most authenticated identity.  And that makes it
> impossible to add authentication requirements without breaking a lot of
> (read: all) Clients.
>
> No, there is discussion of authentication and the most authenticated
> user/identity, but specific requirements and filtering are discussed in the
> description of each operation.  In particular, Get-Jobs and
> Get-Job-Attributes talk about filtering based on security policy, while
> Get-Printer-Attributes only talks about filtering based on document format
> (and basically says everyone gets to see the same information).
>
> This is arguably a bug in the original IPP specs, but there is nothing we
> can do to fix Get-Printer-Attributes now.
> (but there are advantages to having a public/guest "get" operation for
> discovering what a Printer will require, e.g.,
> "uri-authentication-supported" values...)
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 27 Jan 2017 16:42:35 +0000

Thanks Ira. I'm still going to write it up in a white paper / technical brief so that I can better outline the use cases, and we can use that to drive our discussion at the Feb. F2F.

Smith

> On Jan 26, 2017, at 11:14 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Sun, Jan 15, 2017 at 10:49 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> Ira,
> 
> > On Jan 15, 2017, at 8:45 PM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi Mike,
> >