attachment
<div dir="ltr">Michael and Paul, thanks very much for your helpful replies! <div><br><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px">Jeremy Leber</b><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"><font color="#32323c" face="arial, helvetica, sans-serif"><span style="font-size:13px;line-height:18px">Area Owner, Network Firmware Development</span></font></div><div dir="ltr"><font color="#32323c" face="arial, helvetica, sans-serif"><span style="font-size:13px;line-height:18px"><br></span></font></div><div dir="ltr"><span style="font-family:arial,helvetica,sans-serif;line-height:18px;font-size:10px;color:rgb(28,100,180)"><b>O</b></span><span style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"> </span><span style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;line-height:18px;font-size:12px">+1 859 825-4505</span><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"><span style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;line-height:18px;font-size:12px"><a href="mailto:jeremy.leber@lexmark.com" target="_blank">jeremy.leber@lexmark.com</a></span><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"><a href="http://www.lexmark.com/" style="font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px" target="_blank"><img src="http://www.lexmark.com/common/images/email/lexmark-logo-email-signature.png" border="0"></a><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"><span style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;line-height:18px;font-size:12px"><a href="http://www.lexmark.com" target="_blank">www.lexmark.com</a></span><br style="color:rgb(50,50,60);font-family:arial,helvetica,sans-serif;font-size:13px;line-height:18px"></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 16, 2016 at 2:52 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Jeremy,<div><br><div><blockquote type="cite"><span class=""><div>On Nov 16, 2016, at 1:34 PM, Jeremy Leber <<a href="mailto:jeremy.leber@lexmark.com" target="_blank">jeremy.leber@lexmark.com</a>> wrote:</div><br class="m_8377001895791116319Apple-interchange-newline"></span><span class=""><div><div dir="ltr">Hi All,<div><br></div><div>I could use some clarification on the proper way to use OAuth with IPP, given the following scenario:</div><div><br></div><div>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><font face="arial, helvetica, sans-serif"><br></font></div><div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><font face="arial, helvetica, sans-serif">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></span></blockquote><div>Yes.</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><font face="arial, helvetica, sans-serif">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></span><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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><font face="arial, helvetica, sans-serif">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)"><li style="box-sizing:border-box;margin-left:0px"><font face="arial, helvetica, sans-serif">uri-authentication-supported MUST contain 'oauth' if OAuthv2 is supported</font></li></ul></div></div></div></blockquote></span>Yes</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px"><font face="arial, helvetica, sans-serif">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></span><div>Yes</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px"><font face="arial, helvetica, sans-serif">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"><li style="box-sizing:border-box;margin-left:0px"><font face="arial, helvetica, sans-serif">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></span>Yes and yes.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51)"><li style="box-sizing:border-box;margin-top:0.25em;margin-left:0px"><font face="arial, helvetica, sans-serif">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></span>Correct.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><font color="#333333" face="arial, helvetica, sans-serif">And a few extra questions:</font></div><font color="#333333" face="arial, helvetica, sans-serif"><ul><li>Has any discussion or consideration been had regarding using ID tokens to represent the job owner (i.e. the requesting-user-name)?<br></li></ul></font></div></div></div></blockquote></span>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/<wbr>uri" attributes.</div><span class=""><div><blockquote type="cite"><div><div dir="ltr"><div><font color="#333333" face="arial, helvetica, sans-serif"><ul><li><font face="arial, helvetica, sans-serif">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">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></li></ul></font></div></div></div></blockquote></div></span>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><br><div>
<span class="m_8377001895791116319Apple-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;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word"><span class="m_8377001895791116319Apple-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;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word">______________________________<wbr>___________________________<br>Michael Sweet, Senior Printing System Engineer</div></span></div></span>
</div>
<br></div></div></blockquote></div><br></div>