Hardly, since flexible implementations can be made to work for all
cases. I would also think that if IPP is unable to handle the group
password configuration at all, then its acceptance will be extremely
limited. If you're concerned about username spoofing, digest
authentication doesn't provide that much additional protection.
I've asked this question before without an answer - do any current
network interfaces or print servers for printers have sufficient
resources to store 1000's of usernames and passwords for HTTP
authentication? I think the answer to this is "no".
Aside from resources there is also the issue of account management.
It's a lot easier to manage a dozen accounts on a printer than it is
to manage a 1000.
> To allow your example to work, IPP would need the concept of users
> and group membership. It has only the former.
> ...
No, it needs no such nonsense. I've outlined the implementation
requirements to support both HTTP and IPP user names:
if requesting-user-name is provided, use it
else if HTTP user name provide, use it,
else use "guest" account
The HTTP authentication would verify that the user has access
priviledges, and after that point the server needs to trust the
contents of the IPP request. The HTTP access control stuff goes
beyond anything in IPP and shouldn't affect the request once it
gets into the server.
Let me say this again - because Basic and Digest authentication are
not secure, the HTTP username is no more authoritative than the IPP
requesting-user-name attribute. Ignoring the requesting-user-name
attribute will not improve IPP security at all, but *will* hamper its
ability to function in large installations.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com