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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20240620/645e8be7/attachment.sig>