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

From: Randy Turner <[email-masked]>
Date: Wed, 17 Dec 1997 00:33:56 -0800

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.

---

From: [email-masked] (Robert Herriot)
Date: Tue, 16 Dec 1997 20:30:36 -0800

I have enclosed the existing wording and my proposed wording below.

I have added the language about the gateway that I was asked to add
and I have tightened the language to make things (hopefully) clearer.
I have addressed cases that are not addressed with the current language.

-------------------------------------------------------------------------

3.1.5.2	The "requesting-user-name" Operation Attribute

Existing Wording:

A Printer object SHALL support the MANDATORY "requesting-user-name"
operation attribute that a client SHOULD supply in all operations.
This operation attribute is provided in case (1) there is no security
service being used, (2) the client and Printer object negotiate to no
authorization, or (3) the authentication service does not make
available to the Printer object an authenticated printable
representation of the user's name that is making the request.  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.

For create requests the Printer object, upon creating a new Job object,
SHALL store the originating user's name in the MANDATORY
"job-originating-user-name" Job Description attribute.  The
"job-originating- user-name" attribute is used for presentation only,
such as returning in queries or printing on start sheets, and is not
used for matching the authenticated principal of subsequent
operations.  If the Printer object has access to a more authenticated
printable representation of the user's name, the Printer object SHALL
store that value instead of the value supplied by the client in the
"requesting-user-name" operation attribute.

The Printer object, upon creating a new Job object, SHALL store the
originating user's principal credential in an internal
implementation-dependent Job Description attribute.  This attribute is
not specified as part of IPP, since it is not of any interest to
clients.  However, the Printer object uses this internal attribute for
matching the authenticated principal id of subsequent operations.  If
the Printer object has access to a more authenticated representation of
the user's id, the Printer object SHALL store that value instead of the
value supplied by the client in the "requesting-user-name" operation
attribute.  Otherwise, the Printer object SHALL store the value
supplied by the client in the "requesting-user-name" operation
attribute.

-------------------------------------------------------------------------

Proposed wording:

	

	

	
       “requesting-user-name”.

	

The human readable name: