IPP>MOD action item: revised text for requesting-user-name

IPP>MOD action item: revised text for requesting-user-name

IPP>MOD action item: revised text for requesting-user-name

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu Dec 18 22:32:21 EST 1997


The following wording replaces all of in section 8.6 according to the
agreement at todays telcon.
----------------------------------------------


8.6 The "requesting-user-name" Operation Attribute




Each operation SHALL specify the user who is performing the operation
in both of the following two ways:


	1) via 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. If the
	client does not supply a value for "requesting-user-name", the printer
	SHALL assume that the client is supplying some anonymous name, such as
	"anonymous".
	
	2) via an authentication mechanism of the underlying transport which
	may be configured to give no authentication information.


There are six cases to consider:


	a)  the authentication mechanism gives no information, and the client
	doesn't 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  doesn't specify
	"requesting-user-name".
	
	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 who is trusted and
	whose name means that the value of the "requesting-user-name", which
	must be present, is treated as the authenticated name.


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
	
	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 user 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 "anonymous" for cases a and c.


The user 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 "anonymous" for case a.


The essence of these rules for resolving conflicting sources of
user-names is that a printer implementation is free to pick either
source as long as it achieves consistent results.  That is, if a user
uses the same path for a series of requests, the requests must all
appear to come from the same user from the standpoint of both the
human-readable user name and the user name for authorization  This rule
must continue to apply even if a request could be authenticated by two
or more mechanisms.  It doesn't matter which the several authentication
mechanism a Printer uses as long as it achieves consistent results.  If
a client uses more than one authentication mechanism, it is recommended
that an administrator make all credentials resolve to the same user and
user-name as much as possible.



More information about the Ipp mailing list