IPP and OAuth
This page tracks our discussions and consensus regarding IPP and OAuth.
- Add discussion of filtering "operations-supported" to the errata update of PWG 5100.11-2010: IPP Job and Printer Extensions - Set 2 (JPS2) (now titled "IPP Enterprise Printing Extensions v2.0 (EPX)") as part of the description of the Get-User-Printer-Attributes operation.
- Errata update of PWG 5100.18-2015: IPP Shared Infrastructure Extensions v1.0 (INFRA) to address known issues and add explicit OAuth/X.509 support
- Errata update of PWG 5100.22-2019: IPP System Service v1.0 (SYSTEM) to address known issues and add explicit OAuth/X.509 support
- Errata update of PWG 5199.10-2019: IPP Authentication Methods v1.0 to amend OAuth recommendations/descriptions
- New PWG 5199.x: Cloud Printing with IPP Everywhere v1.0 best practice for cloud printing
- Update sequence diagram to include: -- PKCE instead of Client ID / Client Secret in authorization code flow -- Client validating certificates or something else provided by the printer and the Authorization Server to validate they are both taking part in the same ecosystem
Clients needs to validate the hostname used to connect to the Printer/System with the X.509 certificate. Unlike regular printing, a TOFU policy for self-signed certificates cannot be used due to the greater danger of man-in-the-middle attacks exposing OAuth credentials. Clients should ensure that certs are either signed by a trusted root or a specific self-signed certificate has been explicitly allowed.
Proof Key for Code Exchange (RFC 7636) should always be used for Client authorization, SHOULD NOT use implicit flow (matches OAuth WG recommendations/best practices).
Device Authorization Grant (RFC 8628) can be used to onboard Printers to well-known public Cloud printing services, just as is done for "logging in" for common video streaming platforms. A QR code or URL can be displayed or printed that can be opened on a mobile device to authorize access for the Printer via a user account.
Usage should be documented in a separate "Cloud Printing with IPP Everywhere" best-practice document - System service for the Register-Output-Device operation and any OAuth/X.509 stuff, then INFRA for the Printer/Proxy to grab jobs from the cloud service.
Token Exchange (RFC 8693) should be used to further minimize disclosure of Client credentials and to validate the Printer/System with the OAuth authorization server. The "resource" value is the "printer-uri" or "system-uri" that was used to connect to the Printer/System. One further benefit is that the issued tokens can have a relatively short lifetime to minimize the chances of tokens being reused for malicious purposes.
Scopes can map to IPP access roles (End User, Operator, Administrator), but OAuth doesn't define a set meaning and they get used for many different purposes (roles, access rights, etc.) A Printer/System advertises all of the scopes that are assigned (usually out of band from IPP) for use with that Printer/System in the "oauth-authorization-scope (1setOf name(MAX))" Printer/System Description attribute, and the Client requests those scopes when getting an authorization grant token. The Client can use the Get-User-Printer-Attributes operation to query the subset of operations that are allowed once authorization is granted, but otherwise there is no way to know what the scopes mean. This usage of Get-User-Printer-Attributes is not limited to OAuth.
From a Client perspective, scopes are opaque strings (included in auth request). From a Printer perspective, scopes need to be configured (out of band) to map to access roles or capabilities (e.g. can print color). The Client has to get separate tokens for multiple printers if the scopes and/or authorization servers differ. Token Exchange can reuse Access Token if the scopes are the same.
Recommend OpenID to implement roles/permissions instead of scopes in order to avoid caching issues.
Note: Requires additional research.
TPM 2.0 provides a platform identity device ID and certificate. Once connected to a network, it generates a local device ID derived from the platform and network IDs. Certification guarantees uniqueness and the unique keys are generated during manufacturing with a certificate issued by trusted CA.
- Mike: What about certificate/key expiration/revocation?
- Ira: Silent about revocation, root key is immutable, other keys can be regenerated
- Ira will investigate limitations of certificate life time, renewal
The TPM might be used to generate an X.509 certificate that would be more trustworthy than a self-signed cert (important to OAuth authorization flow to confirm identity of printer)
- Client prints to cloud, Printer/Proxy pulls processed document data from cloud, Client and Printer authorize using OAuth/X.509
- Client prints to Printer, Printer processes document data locally, Client and Printer authorize using OAuth/X.509
- Client prints to Printer, Printer pushes document data to cloud and pulls processed document data from cloud, Client and Printer authorize using OAuth/X.509
OAuth authorization server and Infrastructure Printer can be local or cloud-based.
OAuth implementation choices can impact performance - JWT (JSON Web Token) allows each party to know the details of the authorization without introspection back to the authorization server, can be validated "offline".
PDF Version: ipp-authentication-6-http-oauth2.pdf
SVG Version (should appear in your browser):
