Re: [IPP] Possible updates to IPP INFRA

Cihan,

Right now I think the path of least resistance is to develop an IPP Registration document that extends the IPP System Service Register-Output-Device operation to support the Proxy's X.509 certificate.  Proposed attributes are:

- "output-device-x509-certificate (1setOf text(MAX))" operation attribute, to be included in the request.
- "output-device-x509-certificate-supported (boolean)" System Description attribute, to tell the Client that the extension is supported.
- "output-device-col-supported (1setOf collection)" Printer Description attribute, to tell the Client which output devices are registered with a given Infrastructure Printer.  Member attributes would be "device-name (name(127))", "device-uuid (uri)", and "device-x509-certificate (1setOf text(MAX))".

The model section (4) of the registration can talk about all of the other concerns you've raised and provide pointers to IPP INFRA, IPP SYSTEM, IPP TRUSTNOONE, and CLOUDMODEL.  We should also talk about OAuth and the use of different authentication methods depending on the configuration and usage, e.g., personal printer connected to a Cloud Imaging System vs. enterprise printer where the Client/End User is a customer or employee.

Longer term we can add this content to an IPP System Service errata update, with a corresponding IPP Shared Infrastructure Extensions errata update that has pointers to IPP SYSTEM.

> On May 15, 2020, at 8:49 AM, Cihan Colakoglu via ipp <ipp@pwg.org> wrote:
> 
> Hello All,
>  
> I was reading the IPP INFRA Spec. (PWG 5100.18-2015:) and found some confusing areas (at least to me).
> Also had some questions about using X.509 certificates for registering the output device through the Proxy to the Cloud.
> I was wondering if an update to IPP INFRA would be warranted, or if we can do an Errata, or maybe even a Best Practice.
>  
> Regarding the issues with Registering an Output Device:
> ·         The INFRA Spec defines “Deregister-Output-Device” operation, but it does not define “Register-Output-Device”.
> ·         Instead, the INFRA Spec says “Update-Output-Device-Attributes” is the inverse of “Deregister-Output-Device”.
> ·         However, IPP System Service (PWG 5100.22-2019:) defines the “Register-Output-Device” and refers to INFRA.
> ·         INFRA does not refer to SYSTEM since INFRA was finalized in 2015, and SYSTEM was finalized in late 2019.
> ·         I understand now INFRA assumed registration was done out-of-band, and it just dealt with an existing association.
> ·         If we update INFRA, we may want to clarify the Registration/Provisioning piece was defined in the SYSTEM Spec.
>  
> Regarding using X.509 Certificates to establish cryptographic pairing during Registration of the Output Device:
> ·         The “Register-Output-Device” operation in SYTEM Spec. does not appear to have an attribute to use a certificate.
> ·         If we want to allow the use of X.509 Certificates for registration, I suppose we could define a new operation attribute.
> ·         There is also the question if a Self-Signed certificate can be used, or if we need a CA-Signed one (Private or Public).
> ·         If we define this, we may want to separate the “Client-to-INFRA-Printer” piece from “Proxy-to-INRA-Printer” piece.
> ·         Then, how would we define what an Admin can do from the Cloud Dashboard/Portal once the Registration is done?
> ·         Should the Registration be done ONLY from the Proxy to the Cloud, and not through the Cloud Portal for security?
>  
> Regarding possible Cloud to Cloud communication use-cases
> ·         In some instances, jobs may need to travel through multiple Clouds to get to the final Output Device.
> ·         I don’t believe IPP INFRA addresses this specifically, however could the Classic fan-out with IPP used for this?
> ·         If we do an update to INFRA, we may want to clarify how this type of communication could be handled with IPP.
>  
> Regarding the IPP Specifications relevant to a Cloud Model:
> ·         I think not everyone can navigate easily through all available (Historic and Current) IPP Specifications.
> ·         So, we may want to list the relevant specifications within the scope of a Cloud Printing model:
> o   IPP INFRA (PWG 5100.18-2015:)
> o   IPP System Service (PWG 5100.22-2019:)
> o   IPP Encrypted Jobs and Documents (Working Draft)
> o   Cloud Imaging Requirements and Model (Link)
> o   Any other?
>  
> I wanted to start a discussion whether it is warranted to update IPP INFRA all together, do an Errata, or a Best Practice.
> 
> Best Regards,
> Cihan Colakoglu
> Kyocera Document Solutions
>  
> 
>  
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

________________________
Michael Sweet

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp