If your scenario of a group name for digest authentication is likely, then
we could have two additional values for the "authentication-supported":
"basic-requesting-user-name" and "digest-requesting-user-name". The first
means that both basic authentication and the requesting-user-name are used
and that they may be different. The meaning of the second is similar except
with "digest".
Such a change would mean that the attribute "job-originating-user-name"
would have to keep both names encoded in some syntax, such as
"basic-name,requesting-user-name" if they are different. It would also mean
that the hierarchy of authenication could not include these two if the names
were different.
With regard to your suggestion of "authentication-required" attribute, the
"authentication-supported" that I proposed serves that function.
Bob Herriot
> -----Original Message-----
> From: Michael Sweet [mailto:mike@easysw.com]
> Sent: Thursday, March 25, 1999 7:27 PM
> To: Herriot, Robert
> Cc: ipp@pwg.org
> Subject: Re: IPP> MOD - Issue 2: How can client force authentication,
> i.e., identified mode? Solution #2 preferred
>
>
> "Herriot, Robert" wrote:
> >
> > I prefer solution #2 because it avoids adding a new and
> rather strange
> > operation. Instead it adds some new attributes and fits in with the
> > existing infrastructure. Solution #2 is:
> > ...
> > To resolve the ISSUE in the above solution, I suggest that we add a
> > printer attribute "authentication-supported", which we
> would also add
> > to the printer template for SLP. This attribute would specify how a
> > printer authenticates a client -- a service that is
> incomplete in IPP.
> > The values of this attribute would be parallel to
> > "printer-uri-supported" and "uri-security-supported", and
> would > include:
> > ...
>
> I think ignoring the "requesting-user-name" attribute is a bad idea
> under any circumstances. HTTP authentication is separate from the
> IPP request, and in many cases the HTTP username may be different
> from the actual requesting user (i.e. a group username/password to
> get access to the printer, with the IPP requesting user name used
> for accounting).
>
> The best option might be to add a "authentication-required"
> attribute that defines what kind of authentication is required for
> each URI in "printer-uri-supported". The values would be "None",
> "Basic", and "Digest" (at a minimum), and for Digest authentication
> the IPP client could then request the current printer state to
> initiate the challenge before the job is sent (there are issues if
> the printer has a time-based nonce...)
>
> (FWIW, our current implementation uses the HTTP username value if
> the "requesting-user-name" value is not specified, but is otherwise
> ignored for purposes of printer accounting)
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike@easysw.com
> Printing Software for UNIX http://www.easysw.com
>