Hugo,
Good question, but considering that there are other mechanisms needed to
invoke SSL3 or TLS, and that the HTTP Basic authentication in HTTP is being
deprecated by the HTTP group, this really only leaves HTTP Digest as a
serious candidade for this in the IPP standard.
Carl-Uno
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Hugo
> Parra
> Sent: Wednesday, March 24, 1999 10:31 PM
> To: hastings at cp10.es.xerox.com; ipp at pwg.org> Subject: Re: IPP> MOD - Issue 2: How can client force
> authentication,i.e., identified mode?
>>> Question on alternative 1: Does the challenge issued by the IPP
> object specify what type of credential the user should send? If
> so, if the IPP object supports more than one
> authentication/security method, which one should it request?
>> -Hugo
>> >>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 03/23/99 06:24PM >>>
> Here is the third issue from the Bake Off that has several possible
> alternatives. This issue has also had a lot of email discussion since the
> Bake Off. We list some additional alternatives to adding a new operation.
> What do people think of the alternatives?
>> Tom
>> 2) ISSUE: How can client force identified mode?
>> If an IPP Printer supports both authenticated and unauthenticated
> access, there is no way for a client to force itself to be
> authenticated, i.e., be in identified mode, since it is the server that
> forces authentication by issuing a challenge to the client. It is
> very useful for a client to be able to get into identified mode as soon
> as possible. Today you have to wait to be challenged by the server,
> which may never happen -- or happens at an unpredictable time. The
> security conformance requires that the authentication for operations be
> the same for all operations. So for authenticated Cancel-Job, the
> Print-Job has to be authenticated as well. We would like to add another
> operation that forces the server to generate a 401 authentication
> challenge which the client would submit before submitting the print job
> in the first place. Unless somebody has a different solution
> (Microsoft)
>>> Possible alternatives:
>> 1.Add the operation as an OPTIONAL operation to IPP/1.0 and IPP/1.1
> that forces the IPP object to issue a challenge to the client.
>> 2.Use two URLs for the same IPP Printer object, one requires
> authentication and the IPP server always issues a challenge and the
> other never does. So the client that wants to be authenticated
> submits requests to the URL that requires authentication. ISSUE: How
> does the client discover which URL to use, since "uri-security-
> supported" is about security, not authentication?
>> 3.Use two IPP Printer objects that fan-in to the same device. One IPP
> Printer object requires authentication and always issues the
> challenge and the other never does. ISSUE: How does the client
> discover which IPP Printer to use for authenticated access?
>> 4.Request that the HTTP WG add some kind of header that allows the
> client to request that the HTTP server issue a challenge. ISSUE: It
> is unlikely that the HTTP group would do such a thing, since it is
> not needed for the usual use of HTTP which is to access documents on
> a server.
>>>>