attachment

<div dir="ltr">Hi Mike, Smith,<div><br></div><div>Yes, "server-uri" is not a registered parameter for the Bearer authentication scheme. </div><div>But if "server-uri" and "scope" were reported in HTTP 401 Response (edge 11), Get-System-Attributes and Get-Printer-Attributes could be protected by OAuth as other requests.</div><div>It would be nice to have this as an option. For public services, Get-System-Attributes and Get-Printer-Attributes are good targets for DDos attacks. It is much easier to compose a 401 HTTP response than a full IPP frame with hundreds of attributes.</div><div><br></div><div>Best regards,</div><div>Piotr</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 9, 2020 at 1:40 PM Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Piotr,<br>
<br>
> On Oct 9, 2020, at 12:48 PM, Piotr Pawliczek <<a href="mailto:pawliczek@chromium.org" target="_blank">pawliczek@chromium.org</a>> wrote:<br>
> <br>
> Hi Smith,<br>
> <br>
> Thank you very much for your help!<br>
> BTW, have you considered using an HTTP response header (see <a href="https://tools.ietf.org/html/rfc6750#section-3" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6750#section-3</a>) to communicate "server-uri" and "scope" to the client?<br>
<br>
"server-uri" is not a registered parameter for the Bearer authentication scheme.<br>
<br>
> In this case, we would not have to expose Get-System-Attributes and Get-Printer-Attributes to everyone.<br>
<br>
These are already exposed to everything - the OAuth server isn't the only bit of information needed.<br>
<br>
> <br>
> Best regards,<br>
> Piotr <br>
> <br>
> On Wed, Oct 7, 2020 at 2:14 PM Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:<br>
> Hi Piotr,<br>
> <br>
> I filed two errata against 5100.22: one to have Get-System-Attributes authentication semantics clarified, and another to have "oauth-authorization-server-uri" and "oauth-authorization-scope" attributes added as System Description attributes. The expectation is that a System object MUST NOT challenge a Client for authentication. Given that, if a System object supported OAuth, it ought to provide the "oauth-authorization-server-uri" and "oauth-authorization-scope" attributes as System Description attributes.<br>
> <br>
> Smith<br>
> <br>
> /**<br>
>     Smith Kennedy<br>
>     HP Inc.<br>
> */<br>
> <br>
>> On Oct 7, 2020, at 2:56 PM, Piotr Pawliczek <<a href="mailto:pawliczek@chromium.org" target="_blank">pawliczek@chromium.org</a>> wrote:<br>
>> <br>
>> Hi Smith,<br>
>> <br>
>> Yes! Thank you very much. This is the problem I run into.<br>
>> I just forgot to check Get-System-Attributes, so I didn't mention it.<br>
>> <br>
>> Piotr<br>
>> <br>
>> <br>
>> On Wed, Oct 7, 2020 at 1:51 PM Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:<br>
>> Hi there,<br>
>> <br>
>> In "IPP Authentication Methods v1.0" on page 19 (<a href="https://ftp.pwg.org/pub/pwg/informational/bp-ippauth10-20190816-5199.10.pdf#page=19" rel="noreferrer" target="_blank">https://ftp.pwg.org/pub/pwg/informational/bp-ippauth10-20190816-5199.10.pdf#page=19</a>), edge 13 says 'Check for "oauth-authorization-server-uri" and "oauth-authorization-scope" Printer Description attributes'. If the IPP System supported OAuth, then presumably a Client could do a Get-System-Attributes operation to get these same two attributes. <br>
>> <br>
>> But if the System is allowed to respond with an authentication challenge (similar to Get-User-Printer-Attributes but not similar to Get-Printer-Attributes) then we have a problem because those two OAuth attributes can't be acquired by the Client. I cannot tell from the definition of "Get-System-Attributes" in IPP System v1.0 (<a href="http://ftp.pwg.org/pub/pwg/candidates/cs-ippsystem10-20191122-5100.22.pdf#page=70" rel="noreferrer" target="_blank">http://ftp.pwg.org/pub/pwg/candidates/cs-ippsystem10-20191122-5100.22.pdf#page=70</a>) whether a System object is allowed to challenge a Client for authentication in response to a Get-System-Attributes operation request.<br>
>> <br>
>> Piotr, did I capture your "chicken-and-egg" concerns here?<br>
>> <br>
>> Smith<br>
>> <br>
>> /**<br>
>>     Smith Kennedy<br>
>>     HP Inc.<br>
>> */<br>
>> <br>
>>> On Oct 7, 2020, at 2:16 PM, Michael Sweet via ipp <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>> wrote:<br>
>>> <br>
>>> Piotr,<br>
>>> <br>
>>> > On Oct 7, 2020, at 4:08 PM, Piotr Pawliczek via ipp <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>> wrote:<br>
>>> > <br>
>>> > Hi,<br>
>>> > <br>
>>> > I am trying to figure out how to implement oauth authentication for the IPP System (e.g.: needed to send the Get-Printers request). I cannot find any references to oauth authorization in the document "IPP System Service v1.0 (SYSTEM)". Is there any plan to describe oauth authentication on the level of IPP System?<br>
>>> <br>
>>> OAuth happens at the HTTP level, so the IPP Authentication Methods v1.0 document applies to all IPP services, not just printing.<br>
>>> <br>
>>> ________________________<br>
>>> Michael Sweet<br>
>>> <br>
>>> <br>
>>> <br>
>>> _______________________________________________<br>
>>> ipp mailing list<br>
>>> <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
>>> <a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
>> <br>
> <br>
<br>
________________________<br>
Michael Sweet<br>
<br>
<br>
<br>
</blockquote></div>