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="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mike,<div class=""><br class=""></div><div class="">I'm not sure how to incorporate your feedback into the current OAuth2 sequence diagram. I will list some of my questions here, but we may need to save discussion till the F2F session.</div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server.</div></div></blockquote><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div>Could that not be implemented such that the client provides its own "web view" able to render web content as per the current OAuth2 sequence diagram?</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Also, if IPP is performed before Step 1, then is the "Step 0" a IPP Get-Printer-Attributes or Validate-Job IPP operation?</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""> The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("<a href="myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df" class="">myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df</a>"), which is how you implement OAuth2 for so-called "native apps".</div></div></blockquote><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div>OK so the HTTP response will be an HTTP 302 or similar, where the URL could be an https scheme, or could be some other scheme? What about the "ipp" scheme? Or maybe that is too premature / inappro. But the token comes in as basically a parameter in the URL in the 30x redirect response?</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the authorization server using a HTTP POST (no web browser needed).</div></div></blockquote><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">So the "grant" is basically an "access token access token" that allows the Client to request an "access token"?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.</div></div></blockquote><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div>And it is up to the Client to manage that access token? Is it typically stored in a cookie or via some other place / method?<br class=""><div class=""><div class=""><div dir="auto" style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless & Standards Architect - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 10:53 AM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Smith,</span><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">OK, so to "help" I think we need to separate things because OAuth2 has three distinct steps:</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server. The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("<a href="myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df" class="">myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df</a>"), which is how you implement OAuth2 for so-called "native apps".</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the authorization server using a HTTP POST (no web browser needed).</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Only step 1 requires a web browser.</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">Only step 3 is in-band of IPP.</div></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The token you get in steps 1 and 2 can potentially be reused indefinitely. When you get a 401 with and error parameter in the WWW-Authenticate header, it is time to either a) refresh the access token or b) repeat steps 1 and 2 to re-authenticate.</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The list of RFCs is extensive (<a href="https://oauth.net/2/" class="">https://oauth.net/2/</a>) but the important ones for IPP are:</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- RFC 6749: The OAuth 2.0 Authorization Framework (doing out-of-band authentication and getting access tokens)</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- RFC 6750: OAuth 2.0 Bearer Token Usage (doing in-band authentication)</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- RFC 7636: Proof Key for Code Exchange (doing out-of-band authentication more securely with native Client applications)</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">- RFC 8252: Recommendations for using OAuth 2.0 with native apps (doing out-of-band authentication on a Client - for implementors)</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The following Internet Draft will (hopefully) define how an input constrained device like a printer can authenticate as a client (important for IPP INFRA proxies).</div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2017, at 3:59 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Mike,<br class=""><br class="">One of my action items to move the IPP Authentication white paper forward was to solicit help from you in correcting the OAuth2 diagram(s). Could you take a look at the attached PlantUML sequence diagram files and make corrections you feel are needed? The versions from the latest white paper (from August) are attached - there are two of them. You can edit it in any text editor, then render it using the PlantUML tool:<br class=""><br class=""><a href="http://plantuml.com/download" class="">http://plantuml.com/download</a><br class=""><br class="">Thanks in advance!<span class="Apple-converted-space"> </span><br class=""><br class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""><span id="cid:CEA9065E8580FB4F99B8E08A9E99099B@NAMPRD84.PROD.OUTLOOK.COM" class=""><ipp-authentication-6-http-oauth2.pu></span><span id="cid:6740B43CAB28CC498F1AF71A309D16FB@NAMPRD84.PROD.OUTLOOK.COM" class=""><ipp-authentication-8-http-oauth2-with-digest.pu></span></div></div></blockquote></div><br class=""><div class=""><span class="Apple-style-span" style="border-collapse: separate; font-family: "Andale Mono"; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><span class="Apple-style-span" style="border-collapse: separate; font-family: "Andale Mono"; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-variant-east-asian: normal; font-variant-position: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer</div></span></div></span></div></div></div></blockquote></div><br class=""></div></div></body></html>