attachment
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1441536288;
mso-list-template-ids:-1;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNoSpacing>Both Michael and Smith make good points, and I think it is mainly a question of how far Smith wants to extend the scope of the document. From his earlier message, it appears that he has added more information on Authorization. However, his comment that the purpose of Authentication in a printer is primarily to support Authorization features is quite to the point. Indeed, the text might point out that the extended authentication mechanisms discussed relate to obtaining the value of the IPP attribute job-originating-user-name, which is used by the printer for authorization checks. That is, <span style='font-family:Consolas'><o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> The Printer sets this attribute to the most<o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> authenticated printable name that it can obtain from the<o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> authentication service over which the IPP operation was received.<o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> Only if such a name is not available does the Printer use the value<o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> supplied by the Client in the "requesting-user-name" operation<o:p></o:p></span></p><p class=MsoNoSpacing><span style='font-family:Consolas'> attribute of the Job Creation request.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Of course, from Michael’s point, discussion of printer-implemented authorization in this document is probably limited to restating what is in STD92: using the <span style='font-family:Consolas'>most authenticated printable name for authorization and IPP responses to authentication failures. </span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, <o:p></o:p></p><p class=MsoNormal>Bill Wagner<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:smith.kennedy@hp.com">Kennedy, Smith (Wireless & Standards Architect)</a><br><b>Sent: </b>Friday, March 1, 2019 10:49 AM<br><b>To: </b><a href="mailto:msweet@msweet.org">Michael Sweet</a><br><b>Cc: </b><a href="mailto:wamwagner@comcast.net">William A Wagner</a>; <a href="mailto:Christopher.Rizzo@xerox.com">Rizzo, Christopher</a>; <a href="mailto:RYardumian@ciis.canon.com">Rick Yardumian</a>; <a href="mailto:ipp@pwg.org">PWG IPP Workgroup</a><br><b>Subject: </b>Re: [IPP] WG Last Call: IPP Authentication Methods</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>How about this:<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-left:30.0pt;margin-right:0in'><div><p class=MsoNormal><b><span style='font-size:13.5pt'>3.4. Out of Scope</span></b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:10.5pt'>The following are considered out of scope for this document:</span><o:p></o:p></p></div><div><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='font-size:10.5pt'>Definition of new HTTP authentication methods</span><o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'><span style='font-size:10.5pt'>Definition of how specific authorization mechanisms are used by an IPP Printer. The Internet Printing Protocol/1.1 [STD92] defines authorization roles for end users, operators, and administrators, but does not define how a Printer or an authorization mechanism maps those roles to authenticated users.</span><o:p></o:p></li></ol></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Feb 28, 2019, at 5:00 PM, Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Bill,<br><br>I think you make a good point.<br><br>Smith,<br><br>I think you can make a general statement about authorization, something along the lines of:<br><br>"Specific authorization mechanisms are outside the scope of this document. The Internet Printing Protocol/1.1 [STD92] defines authorization roles for end users, operators, and administrators, but does not define how a Printer maps those roles to authenticated users."<br><br><br>> On Feb 28, 2019, at 5:50 PM, wamwagner--- via ipp <<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>> wrote:<br>> <br>> Smith,<br>> <br>> Sorry, my confusion continues. Your new Authorization example may be valid, but it seems odd to me that someone would have an account in a printer but not have authority to print at all. Conditional authority, restricting use to certain times or restricting color, or quantity, etc. would be more realistic, but that is at the IPP level and does not appear to be addressed in this specification. <br>> <br>> The title is Authentication Methods, and although I may have missed it, I do not think that it does much with authorization (at least not by the printer), which would occur after successful Authentication. Perhaps the Authorization use case should be put in the out of scope section?<br>> Thanks, Bill W.<br>> <br>> <br>> <br>> From: Rizzo, Christopher via ipp<br>> Sent: Thursday, February 28, 2019 4:12 PM<br>> To: Kennedy, Smith (Wireless & Standards Architect); Rick Yardumian<br>> Cc: PWG IPP WG Reflector<br>> Subject: Re: [IPP] WG Last Call: IPP Authentication Methods<br>> <br>> This update looks good to me.<br>> <br>> Thanks,<br>> Chris<br>> <br>> Christopher Rizzo<br>> Xerox Corporation<br>> GDG/Discovery/Advance Technology<br>> 26600 SW Parkway Ave.<br>> Wilsonville, OR 97070-9251<br>> Phone: (585) 314-6936<br>> <a href="mailto:Christopher.Rizzo@xerox.com">Email: Christopher.Rizzo@xerox.com</a><br>> <br>> "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."<br>> -Maurice Wilkes, Memoirs of a Computer Pioneer<br>> <br>> From: "Kennedy, Smith (Wireless & Standards Architect)" <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>><br>> Date: Thursday, February 28, 2019 at 12:36 PM<br>> To: Christopher Rizzo <<a href="mailto:Christopher.Rizzo@xerox.com">Christopher.Rizzo@xerox.com</a>>, Rick Yardumian <<a href="mailto:RYardumian@ciis.canon.com">RYardumian@ciis.canon.com</a>><br>> Cc: PWG Workgroup <<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>><br>> Subject: Re: [IPP] WG Last Call: IPP Authentication Methods<br>> <br>> Thanks for the feedback Chris! I also received this feedback from Canon's Rick Yardumian (CC'ed). In my LCRC draft, I've resolved this issue by rewriting 3.3.2 to more meaningfully describe an authorization failure. <br>> <br>> Here's the rewrite. Any objections or suggestions?<br>> <br>> Harry is also visiting Andy's office and wants to print from his laptop. He uses his laptop to discover available printers, and selects one listed. The printer is configured to limit access to only authorized users. <br>> <br>> The printer challenges the laptop for authentication, and the laptop presents an authentication dialog to Harry. Harry has an account, and enters the account's username and password. The printer accepts these credentials, but that account is not authorized to access that printer. Harry's laptop shows a notification dialog expressing this to Harry. Harry clicks “OK” and looks for a pencil.<br>> <br>> Smith<br>> <br>> <br>> <br>> On Feb 28, 2019, at 12:33 PM, Rizzo, Christopher <<a href="mailto:Christopher.Rizzo@xerox.com">Christopher.Rizzo@xerox.com</a>> wrote:<br>> <br>> Just curious, but section 3.3 Exceptions of this document has sections 3.3.1 and 3.3.2 which are pretty much exact duplicates of each other, exception being Lisa vs. Harry. Was this intentional?<br>> <br>> Thanks,<br>> Chris<br>> <br>> <br>> Christopher Rizzo<br>> Xerox Corporation<br>> <br>> GDG/Discovery/Advance Technology<br>> <br>> 26600 SW Parkway Ave.<br>> <br>> Wilsonville, OR 97070-9251<br>> <br>> Phone: (585) 314-6936<br>> <br>> <a href="mailto:Christopher.Rizzo@xerox.com">Email: Christopher.Rizzo@xerox.com</a><br>> <br>> "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."<br>> -Maurice Wilkes, Memoirs of a Computer Pioneer<br>> <br>> On 1/17/19, 4:00 PM, "ipp on behalf of Kennedy, Smith (Wireless & Standards Architect)" <<a href="mailto:ipp-bounces@pwg.org">ipp-bounces@pwg.org</a> on behalf of <a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br>> <br>> Greetings,<br>> <br>> This message begins the IPP workgroup Last Call of the IPP Authentication Methods best practice draft, available at:<br>> <br>> <a href="https://protect-us.mimecast.com/s/SCyJCpYK0Ki3RjEvhJ2e3P?domain=ftp.pwg.org">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117.odt</a><br>> <a href="https://protect-us.mimecast.com/s/GWcKCqx5v5ujMp6zCrSZEL?domain=ftp.pwg.org">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117.pdf</a><br>> <a href="https://protect-us.mimecast.com/s/R9D9Crk5w5flB531iG6VEW?domain=ftp.pwg.org">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117-rev.pdf</a><br>> <br>> Please respond with any feedback or comments by doing a "reply all" to this message.<br>> <br>> This last call will end on January 31, 2019 at 10pm PT.<br>> <br>> Cheers,<br>> Smith<br>> <br>> /**<br>> Smith Kennedy<br>> HP Inc.<br>> */<br>> <br>> _______________________________________________<br>> ipp mailing list<br>> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>> <a href="https://protect-us.mimecast.com/s/qqFUCv25A5hzkD02f8ANCY?domain=pwg.org">https://www.pwg.org/mailman/listinfo/ipp</a><br>> <br>> <br>> <br>> _______________________________________________<br>> ipp mailing list<br>> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>> <a href="https://protect-us.mimecast.com/s/qqFUCv25A5hzkD02f8ANCY?domain=pwg.org">https://www.pwg.org/mailman/listinfo/ipp</a><br><br>________________________<br>Michael Sweet<br><br><o:p></o:p></p></div></div></blockquote></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>