[IPP] WG Last Call: IPP Authentication Methods

[IPP] WG Last Call: IPP Authentication Methods

Kennedy, Smith (Wireless & Standards Architect) smith.kennedy at hp.com
Fri Mar 1 20:44:46 UTC 2019



> On Mar 1, 2019, at 8:56 AM, Michael Sweet <msweet at msweet.org> wrote:
> 
> Smith,
> 
> I don't think the second sentence belongs there, but maybe in the introduction to make it clear that this document talks about authentication methods, not authorization?
> 

Hopefully my edits to section 4 provide that clarification? Either way, I'll just ditch the second sentence from section 3.4 item 2. I've merged the second sentence into the top of the third paragraph of Section 4:


4. Client Authentication Methods

Authentication is the process of establishing some level of trust that an entity is who or what they are claiming to be. A Printer uses the “authenticated identity” or the “most authenticated user” [RFC8011] to determine whether to allow the requesting Client access to capabilities such as operations, resources, and attributes. A Printer specifies its supported authentication methods via several IPP attributes. The “uri-authentication-supported” attribute [RFC8011] indicates the authentication method used for a corresponding URI in “printer-uri-supported” [RFC8011]. The “xri-authentication” member attribute of “printer-xri-supported” [RFC3380] specifies the same corresponding values, if the Printer implements the “printer-xri-supported” attribute. Each of the authentication method keywords currently registered for “uri-authentication-supported” is described in its own subsection below.

When handing an IPP Job Creation request, the Printer will need to populate the Job's “job-originating-user-name” Job Status attribute. In cases where the Printer relies upon an external authentication service, it will need to acquire a meaningfully printable value from the authentication service.

The Internet Printing Protocol/1.1 [RFC8011] 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. The Printer or the Job might also need to store a token or identifier (UUID, JWT, etc.) that represents the User's authenticated identity or authentication session, in cases where the Printer depends on an external authorization service for print policy evaluation. This token is considered by IPP to be an internal implementation detail, and is not available to Clients via IPP, as discussed in [RFC8011] section 5.3.6.

One authentication system not described below is SAML (Security Assertion Markup Language)[SAMLCORE]. As of this writing, none of the standard SAML bindings to HTTP directly support IPP. SAML can indirectly support OAuth2 via a SAML / OAuth2 gateway. The bridge typically uses the SAML 2.0 assertion as an OAuth 2.0 Bearer token. Specific instructions for how to configure this depends on the SAML and OAuth2 system implementations, and is beyond the scope of this document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190301/0c317445/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/20190301/0c317445/attachment.sig>


More information about the ipp mailing list