Consider the typical network printer - is there enough persistent
memory to store usernames and passwords for 1000's of users?
I'm thinking of our college/university customers, many of whom do
exactly the type of group access control I mentioned in my previous
message. It isn't feasible to manage separate usernames and passwords
on 100's of printers and systems independently, so they assign
usernames and passwords to groups that need access to common
resources. These accounts are changed every 4 months, and with
a robust enough server implementation (that logs the time and IP
or hostname of the requestor) you can track down abusers pretty
quickly.
Also, given the current (lack of) transport-level encryption in
IPP/1.0 (and likely in most IPP/1.1 products), HTTP authentication
is just as prone to spoofing as the requesting-user-name field in
the IPP request.
> 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".
I still don't like making the requesting-user-name attribute that
weak. In the group-account scenario it would allow a member of the
group to "anonymously" submit a job...
> 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.
I don't think including the HTTP authentication information in the
IPP attributes is appropriate - aren't we trying to keep IPP
separate from the actual transport protocol?
> With regard to your suggestion of "authentication-required"
> attribute, the "authentication-supported" that I proposed serves
> that function.
"supported" implies that the authentication is optional. I think we
need to define the *required* authentication for each URI supported
by the server (i.e. if there are 4 URIs you can use, then there are
4 authentication-required's). If I understood your previous proposal,
it sounded like you'd have a set of authentication types that were
acceptable, and the client could choose from them (which won't work
unless you store unencrypted passwords so you can compare clear-text
or md5 encoded strings).
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com