IPP> MOD - Issue 2 - Challenge

IPP> MOD - Issue 2 - Challenge

IPP> MOD - Issue 2 - Challenge

Herriot, Robert Robert.Herriot at pahv.xerox.com
Tue Mar 30 17:38:52 EST 1999

If I understand your second case correctly, you are describing current HTTP
behavior with an additional client feature which keeps a user from
accidentally performing an operation if a challenge is not received.

The problem you are solving is a bit different from the one originally
stated.  The original desire was for a printer which would normally not
issue a challenge but which could be asked by a user to issue a challenge
when the user wanted better authentication.
The person who submitted this problem believes that it is important.

I have suggested that if there really is a problem needing a solution, the
simplest solution is for the printer to have two URLs one that always issues
a challenge and one that never issues a challenge.

Bob Herriot 

> -----Original Message-----
> From: Scott Lawrence [mailto:lawrence at agranat.com]
> Sent: Tuesday, March 30, 1999 1:54 PM
> Subject: RE: IPP> MOD - Issue 2 - Challenge
> > I have been pondering about whether we are trying to make life a
> > little too
> > difficult for ourselves when we look for a solution to this
> > issue.
> I'd say that was nicely understated.
> > Why don't we mandate in IPP/1.1 that IPP printers ALWAYS 
> send a challenge
> > for Digest Authentication?
> I'm not clear on why this is an issue; as I see it there are 
> two cases:
> - Print Service wants authentication.
>   The server has all it needs to enforce that today in the HTTP layer.
> - User wants authentication.
>   All that the user needs for this is an indication from the 
> user agent
>   that a particular operation is or is not authenticated, and 
> perhaps some
>   UI mechanism to indicate that it should not be performed without
>   authentication.
> Note that I said 'Print Service' and 'User', _not_ 'Server' 
> and 'Client (or
> User Agent)'.  Software doesn't make these decisions, people 
> do.  Print
> services in some environments will be wide open; anyone who 
> can get the
> packets there has a right to print.  Others will require 
> authentication to
> support accounting or access control.  Some users will want 
> to know that
> they are properly authenticated, or that the print service is 
> authenticated
> (digest is symmetric).
> If IPP needs anything at all, it needs only a recommendation 
> that the User
> have an indication and/or option to require authentication.  
> If the service
> doesn't offer it, then the user can find a service that does.

More information about the Ipp mailing list