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
- Add Get-User-Printer-Attributes to the flow as well
- Generate trust diagram showing how each entity (Client, Authorization Server, Printer, Proxy, Infrastructure Printer) trusts the others
- August F2F Slides
- Smith's OAuth 2.0 Trust Relationships and Use Case Slides
- Google's OAuth White Paper
- OAuth 2.0 Rich Authorization Requests
- Microsoft Universal Print Service
- Google OAuth User Identity
- Internet Draft: ACME-Based Provisioning of IoT Devices
Problem: User has multiple online identities through the same OpenID (OAuth) authorization service. Needs to use home account with home printers and work account with work printers, but all printers advertise the same "oauth-authorization-server-uri" and "oauth-authorization-scope" values.
- The OpenID service will presumably be able to deny the token request in case of a mismatch (home-token accessing work-printer and vice-versa)
- Client then knows to go through the authorization workflow to obtain a new token.
- Is there a way to avoid all of the round trip and provide a better user experience?
- Yes, use different authorization server URIs or scopes for different organizations
- Client/Printer should validate that URI points to known/trusted server/service
- Possibly offer TOFU for new servers, but that can still be a point of attack
- Client/Printer MUST also validate X.509 cert when negotiating TLS connection to server
- Self-signed explicitly not allowed for auth servers, not even for pinned certs
- Public CA-signed (manual process, only for globally registered domains)
- Private CA-signed (ACME or other proprietary/standardized process for locally registered domains)
- IoT ACME: Possible with some known limitations (.local isn't unique, guarantees can't be as strong)
- Self-signed: not allowed for OAuth
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.
- .local certificates cannot be trusted to the same level as a registered domain, even with IoT ACME, because ".local" isn't unique and depends on time-of-use
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.
- Need to use Printer/System URI since that is the resource the Client is accessing and can validate (earlier proposals had the Printer/System supplying a resource value to use, but that can be spoofed)
- Potential issues:
- Resource URIs with mDNS hostnames (printer.local) are not globally unique, what if you get two different printers both registered with the same URI? Smith's OAuth 2.0 Trust Relationships and Use Case Slides
- But most printers have default hostnames based on the MAC address and it is unlikely that OAuth will be used solely with mDNS
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.
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 2.0.
In cases where a single Authorization Service is used for multiple "contexts" (i.e, multiple enterprises or a mixture of enterprises and consumer users), the scopes should be "identifiers" for each "context". These "contexts" could be highly granular such as on a per-printer basis, or they might encompass multiple printers, which you might find in an office or campus "enterprise" context. If the number of scopes is large (greater than 200?) then the scopes should only be listed by the printer via its "oauth-authorization-scope" attribute, and not listed in the discovery metadata JSON information.
Recommend OpenID to implement roles/permissions instead of scopes in order to avoid caching issues.
Also look at the OAuth 2.0 Rich Authorization Requests RFC draft.
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-20230109.pdf
SVG Version (should appear in your browser):
