Prototyping experience for IPP OAuth Extensions v1.0 (OAUTH)

Michael Sweet via ipp <[email protected]> Thu, 20 Jun 2024 13:17:09 -0400
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
All,

This messages serves as notice of prototyping of the IPP OAuth Extensions v1.0 (OAUTH) specification at:

    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippoauth10-20230814.pdf

Implementation has been progressing in multiple projects and (at this point) I can say that what remains is outside the scope of the IPP specification and entirely OAuth/OpenID-specific for the "Resource Server" authorization that the IPP Printer needs to implement for validation.

Code/status:

- CUPS v2.5: https://github.com/OpenPrinting/cups
  - (MERGING) Base OAuth/JWT/X.509 support, client authorization support
  - (PENDING) OAuth server authorization support
- libcups v3.0: https://github.com/OpenPrinting/libcups
  - (DONE) Base OAuth/JWT/X.509 support, client authorization support
- mOAuth v2.0: https://github.com/michaelrsweet/moauth
  - (MOSTLY DONE) OAuth/OpenID Authorization Server for testing
- PAPPL v2.0: https://github.com/michaelrsweet/pappl
  - (IN PROGRESS) OAuth client/server authorization support
- cups-local v3.0: https://github.com/OpenPrinting/cups-local
  - (WAITING-FOR-PAPPL) OAuth client authorization
- cups-sharing v3.0: https://github.com/OpenPrinting/cups-sharing
  - (WAITING-FOR-PAPPL) OAuth client/server authorization

Both cups-local and cups-sharing depend on PAPPL for their OAuth support, which in turn depends on CUPS/libcups for the base OAuth support.

Prototyping Experience/Issues:

- X.509 Validation of CA-Signed Certificates
  - Installing CA-signed certs on printers needs work (ACME-IOT or similar)
- OpenID Authorization Servers are far more consistent than OAuth servers
  - Lack of RFC 8414 metadata support for common OAuth implementations (Github, others)
    - CUPS implementation tries both metadata paths and then has a backup for Github
  - RFC 7636 PKCE code_challenge/verifier vs. OpenID nonce vs. no additional protection during authorization
    - CUPS implementation detects authorization requirements via metadata
- Implementing well-known/authorized list of OAuth servers is probably optimistic:
  - Amazon and Microsoft OpenID solutions (at least) require you to setup/provision your own server, which will have a unique FQDN for your organization's domain (so no single standard URL)
  - Think we need to reword the guidance here to have the administrator populate a list of acceptable Authorization Server URLs that are used by the client
  - This list could be dynamically generated via DHCP option (needs registration) and/or DNS-SD lookup for the organization domain

We'll discuss this during today's conference call...

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)