attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mike and Piotr,<br class="">
<div><br class=""><blockquote type="cite" class=""><div class="">On Oct 19, 2022, at 7:29 AM, Michael Sweet <<a href="mailto:msweet@msweet.org" class="">msweet@msweet.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">CAUTION: External Email<br class=""><br class=""><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Michael Sweet <<a href="mailto:msweet@msweet.org" class="">msweet@msweet.org</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [IPP] IPP OAuth 2.0 question / potential gap: How should the Client manage multiple access tokens or realm identities?</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">October 19, 2022 at 7:29:57 AM MDT<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Piotr Pawliczek <<a href="mailto:pawliczek@google.com" class="">pawliczek@google.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">"Kennedy, Smith (Wireless & IPP Standards)" <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>>, PWG IPP Workgroup <<a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a>>, "Jimmy Wu (HE/HIM/HIS)" <<a href="mailto:Jimmy.Wu@microsoft.com" class="">Jimmy.Wu@microsoft.com</a>>, Pamela Dingle <<a href="mailto:Pamela.Dingle@microsoft.com" class="">Pamela.Dingle@microsoft.com</a>>, Benjamin Gordon <<a href="mailto:bmgordon@google.com" class="">bmgordon@google.com</a>><br class=""></span></div><br class=""><br class="">Piotr,<br class=""><br class=""><blockquote type="cite" class="">On Oct 17, 2022, at 5:49 PM, Piotr Pawliczek <<a href="mailto:pawliczek@google.com" class="">pawliczek@google.com</a>> wrote:<br class=""><br class="">Hi Michael and Smith,<br class=""><br class="">Regarding the implementation of the client, I would keep two caches:<br class="">1. access tokens for printers indexed by "printer-uri" (or for IPP Systems indexed by "server-uri")<br class=""></blockquote><br class="">I guess I figured we'd want to "pin" the OAuth server URI and scope with the printer/system ("resource") URI...<br class=""></div></blockquote><div><br class=""></div>I think I agree with this but the primary "key" would be the printer-uri, and the value / record would need to include the "device" access token acquired earlier following token exchange.</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">2. access tokens for Authorization Servers indexed by "oauth-authorization-server-uri" and "oauth-scope"<br class=""></blockquote></div></blockquote><div><br class=""></div>This sounds a bit awkward but I agree with this in principle. </div><div><br class=""></div><div>However, I want to come back to an ambiguity that I still think we need to work out. I've attached a use case diagram from the PDF I posted to the wiki page.</div><div><br class=""></div><div>As we have already established, a mobile Client such as a laptop or smartphone may discover and interact with multiple printers, and those printers may be in different "contexts" or "domains" (e.g. at "work" and at "home"). It is possible that all the printers the Client encounters may not list unique hostnames for "oauth-authorization-server-uri" on a per-context or per-domain basis; both the "work" and "home" contexts may both be served by "<a href="http://authz.x.io" class="">authz.x.io</a>".</div><div><br class=""></div><div>That means that the Client is unable to distinguish the different contexts using the hostname. If in step 3, the Client doesn't provide an identifier for that printer (e.g. certificate or "printer-uuid" or something else unique to that printer), "<a href="http://authz.x.io" class="">authz.x.io</a>" won't know whether the credentials provided in step 3 are legitimate for the "context" that the printer belongs to. Waiting until step 6 and potentially returning another HTTP 401 in step 7, would be a bad user experience, wouldn't it?</div><div><br class=""></div><div>So what value should the Client be providing in step 20 of the big sequence diagram (<a href="https://github.com/istopwg/ippsample/files/9427540/ipp-authentication-6-http-oauth2.pdf" class="">ipp-authentication-6-http-oauth2.pdf</a>) so that the printer / context can be conveyed? Did we ever come to consensus on that?</div><div><br class=""></div><div><br class=""></div><div><img apple-inline="yes" id="3D943935-91B0-41D1-B2E5-AA919AF3F742" src="cid:54BD764C-6DBB-40FB-B387-3BA3987809A8" class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><br class="">When the client communicates with a printer the cache 1 is used (when the printer requires OAuth). If the printer is missing there or the current access token is rejected the client queries "oauth-authorization-server-uri" and "oauth-scope" from the printer and tries to match an entry in the cache 2. If the entry is found the client does TokenExchange (in the background) to get the new access token for the printer (and saves the new access token in the cache 1). If there is no matching entry in the cache 2, the client must go through the authorization procedure to get an access token for the authorization server and given scope ("oauth-authorization-server-uri" and "oauth-scope"). The authorization procedure here means standard Authorization Code flow with PKCE (opening the internet browser, letting the user to authenticate etc).<br class="">Both these caches are kept in the context of the current OS user session (they are wiped out when the user closes the session).<br class=""></blockquote><br class="">I think we need to support persistence beyond the current session, at least for "system" accounts and other background processes that might need access even after the user has logged out (accounting, monitoring, general printing, etc.) But for normal user sessions I agree the cached tokens can go away.<br class=""><br class="">________________________<br class="">Michael Sweet<br class=""><br class=""><br class=""><br class=""></div></blockquote></div><br class=""></body></html>