See my comments on the new proposed
text below...
Randy
Robert Herriot wrote:
..snip..
>> Proposed wording:
>> Each operation SHALL specify the user who is performing the operation
> in two ways:
>> 1) via the the MANDATORY "requesting-user-name" operation attribute
> that a client SHOULD supply in all operations. The client SHALL obtain
> the value for this attribute from an environmental or network login
> name for the user, rather than allowing the user to supply any value.
>> 2) via an authentication mechanism of the underlying transport which
> may be configured to give no authentication information.
I think implementers would like to know if the relationship
between the above 2 ways is: "either-or","and",or just "or".
>> There are six cases to consider:
>> a) the authentication mechanism gives no information, and the client
> doesnt specify requesting- user-name.
>> b) the authentication mechanism gives no information, but the client
> specifies requesting-user- name.
>> c) the authentication mechanism specifies a user which has no human
> readable representation, and the client doesnt specify
> requesting-user-name.
I'm not sure that it is entirely unreasonable to
require credentials to always map to a human
readable string representation. I know this
info is available on x.509 certificates.
>> d) the authentication mechanism specifies a user which has no human
> readable representation, but the client specifies
> requesting-user-name.
>> e) the authentication mechanism specifies a user which has a human
> readable representation. The Printer object ignores the
> ?requesting-user-name?.
>> f) the authentication mechanism specifies a user which is special and
> means that the value of the requesting-user-name, which must be
> present, is treated as the authenticated name.
I do not think scenario (f) should be included
in this list. It sounds like a real niche
case that might take alot of text to explain
why this is needed.
>> The user-name has two forms:
>> one that is human readable: it is held in the MANDATORY
> "job-originating-user-name" Job Description attribute which is set
> during the job creation operations. It is used for presentation only,
> such as returning in queries or printing on start sheets
In the original existing case, we stated that
the originating-user-name should come from the
client's notion of an OS login name, or some
equivalent, locally (on the client host)
authenticated mechanism. If this is still the
case, then I do not think we should preclude
an IPP server from performing some type of
lightweight authentication and access control
using the originating-user-name. However, as
always, when using a secure IPP connection, the
TLS authentication would ALWAYS take precedence.
Randy
>> one for authorization: it is held in an undefined (by IPP) Job object
> attribute which is set by the job creation operation. It is used to
> authorize other operations, such as Send-Document, Send-URI,
> Cancel-Job, to determine the user when the my-jobs attribute is
> specified with Get-Jobs, and to limit what attributes to return with
> Get-Attributes and Get-Jobs.
>> The human readable name:
>> is the value of the requesting-user-name for cases b, d and f.
>> comes from the authentication mechanism for case e
>> is some anonymous name, such as guest for cases a and c.
>> The name used for authorization:
>> is the value of the requesting-user-name for cases b and f.
>> comes from the authentication mechanism for cases c, d and e
>> is some anonymous name, such as guest for case a.