IPP and OAuth

This page tracks our discussions and consensus regarding IPP and OAuth.

X.509 Certificate Validation

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

Note: Fill this out.

Proof Key for Code Exchange (RFC 7636) should be used for Client authorization.

Token Exchange

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.

Trusted Platform Module (TPM)

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)

Updated UML Sequence Diagram (Beta)

ipp-authentication-6-http-oauth2.pdf