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; -webkit-line-break: after-white-space;" class="">Jeremy,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 16, 2016, at 1:34 PM, Jeremy Leber <<a href="mailto:jeremy.leber@lexmark.com" class="">jeremy.leber@lexmark.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">I could use some clarification on the proper way to use OAuth with IPP, given the following scenario:</div><div class=""><br class=""></div><div class="">I have an IPP endpoint that requires verification of the client's identify and validation of the client's authorization before printing a job. The client has obtained an OAuth token that will be used for this purpose.</div><div class=""><font face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><font face="arial, helvetica, sans-serif" class="">When implementing this, should the implementor assume that IPP allows and expects OAuthv2 tokens to be included in the HTTP header (as would be the case for any other HTTP request)? </font></p></div></div></div></blockquote><div>Yes.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><font face="arial, helvetica, sans-serif" class="">If this IS the case, does the system expect any other user authentication information in the IPP request itself?</font></p></div></div></div></blockquote><div>Per RFC 2911, the "requesting-user-name" attribute (and/or the "requesting-user-uri" attribute from PWG 5100.13) can be supplied in a request, but the OAuth2 identity would be considered more authoritative.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><font face="arial, helvetica, sans-serif" class="">As an implementor, when implementing an IPP service with OAuth, are the following assumptions correct?</font></p><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><li style="box-sizing:border-box;margin-left:0px" class=""><font face="arial, helvetica, sans-serif" class="">uri-authentication-supported MUST contain 'oauth' if OAuthv2 is supported</font></li></ul></div></div></div></blockquote>Yes</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px" class=""><font face="arial, helvetica, sans-serif" class="">oauth-authorization-server-uri MUST contain the OAuthv2 authorization URI to be used to authorize the user if uri-authentication-supported contains 'oauth'</font></li></ul></div></div></div></blockquote><div>Yes</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px" class=""><font face="arial, helvetica, sans-serif" class="">The users actual OAuthv2 token MUST be supplied in the HTTP Header Authorization line as a Bearer Token per the Oauth RFC</font><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:0px" class=""><li style="box-sizing:border-box;margin-left:0px" class=""><font face="arial, helvetica, sans-serif" class="">The IPP service will/may authorize access to the printer/device using the supplied OAuthv2 token</font></li></ul></li></ul></div></div></div></blockquote>Yes and yes.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)" class=""><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px" class=""><font face="arial, helvetica, sans-serif" class="">access-oauth-token and access-oauth-uri are only used to access a Document on behalf of the user to be processed by the service not for printer/device access itself</font></li></ul></div></div></div></blockquote>Correct.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><font color="#333333" face="arial, helvetica, sans-serif" class="">And a few extra questions:</font></div><font color="#333333" face="arial, helvetica, sans-serif" class=""><ul class=""><li class="">Has any discussion or consideration been had regarding using ID tokens to represent the job owner (i.e. the requesting-user-name)?<br class=""></li></ul></font></div></div></div></blockquote>Some of the work in the IDS Model document included elements for this, and the IPP System Service specification adds a "job-owner-col" Job Status attribute that could be extended to include a member attribute, but right now an implementation just copies the name and ID (as a URI, so this could be an email address, etc.) to the "job-originating-user-name/uri" attributes.</div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><font color="#333333" face="arial, helvetica, sans-serif" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">If the authentication process using SAML or OpenID Connect, it may retrieve a JWT or SAML Assertion which contains the user's identity, h</font><span style="font-family:arial,sans-serif" class="">as any discussion been had about the benefits or pitfalls or delvierying the JWT/Assertions as the identity instead of a simple requesting-user-name?</span><br class=""></li></ul></font></div></div></div></blockquote></div>We haven't discussed this specifically, however the "requesting-user-name/uri" attributes are considered non-authoritative - implementations are supposed to copy the most authoritative values.</div><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer</div></span></div></span>
</div>
<br class=""></div></body></html>