[IPP] Updated stable draft of IPP Authentication Methods posted

[IPP] Updated stable draft of IPP Authentication Methods posted

Kennedy, Smith (Wireless & Standards Architect) smith.kennedy at hp.com
Mon Mar 4 21:25:20 UTC 2019



> On Mar 4, 2019, at 2:10 PM, Michael Sweet <msweet at apple.com> wrote:
> 
>>> One addition I'd like to see to see for the "requesting-user-name" method is a note that some Clients use a constant identity as a privacy defense (e.g., "mobile" from iOS Clients) when sending requests, so from a Printer's perspective this method is basically useless.  In the context of GDPR, this falls under a need for explicit consent - a password challenge or Client UI requesting permission to provide the real user name is required.  At Apple we decided to always hide the requesting user on iOS for basic privacy reasons, relying on authentication where such information is genuinely needed.
>> 
>> Do you want this in section 4.2 "The 'requesting-user-name' IPP Authentication Method" (using numbering from the non-rev documents), or in 5.1.1. "General Recommendations" (for Clients), or 7.2. "Client Security Considerations"? There seems to be two different statements: what is done in the field, and what a Client or Printer ought to do.
> 
> I was thinking of this being in section 4.2.  As far as the general recommendations for clients, I think we need to make a note of privacy concerns, .i.e., recommend that Clients don't just throw the current username in there without getting explicit permission from the User.

I am fine with that - how's this for an updated section 4.2:

4.2. The 'requesting-user-name' IPP Authentication Method

The 'requesting-user-name' IPP Authentication Method [RFC8011] indicates that the Client is to provide the “requesting-user-name” operation attribute [RFC8011] in its IPP operation request. The Printer uses this unauthenticated name as the identity of the User operating the Client. This method is not recommended if job accounting or access authorization is important, since the Printer does not challenge the Client to prove the identity claimed in the “requesting-user-name”. Some Clients always send a fixed identity name (e.g. “mobile”) as a privacy defense when sending requests. As such, from a Printer's perspective, this method is increasingly undependable.

I wonder if we need to call out the notion of authentication as a form of explicit consent to share information, especially within the context of privacy concerns such as GDPR compliance? Where might we put that? The start of Section 4 "Client Authentication Methods"? Or down in Security Considerations?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190304/c0f03849/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190304/c0f03849/attachment.sig>


More information about the ipp mailing list