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.