IPP>MOD Action Item from LA: fix requesting-user-name explanation

IPP>MOD Action Item from LA: fix requesting-user-name explanation

IPP>MOD Action Item from LA: fix requesting-user-name explanation

Randy Turner rturner at sharplabs.com
Wed Dec 17 03:33:56 EST 1997


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.



More information about the Ipp mailing list