I think we agree that if b) above provides no authentication information, then
the user name comes from a). If neither channel provides a user name, then
the user is "guest" or something similar.
The issue we are disagreeing on is where both channels provide
authentication information. In that case, MUST the server always use b) and
ignore a) or can an implementation be configured to use a)? If an
implementation can be configured to use a), then it can either
1) do it for all values it obtains from b) or
2) only for certain values it obtains from b).
I was suggesting 2) because it is more likely to be useful. Furthermore,
2) is a superset of 1).
Bob Herriot
> From rturner@sharplabs.com Wed Dec 17 13:50:15 1997
> From: "Turner, Randy" <rturner@sharplabs.com>
> To: "'Robert.Herriot@Eng.Sun.COM'" <Robert.Herriot@Eng>, rturner@sharplabs.com
> Cc: hastings@cp10.es.xerox.com, ipp@pwg.org
> Subject: RE: IPP>MOD Action Item from LA: fix requesting-user-name explana
> tion
> Date: Wed, 17 Dec 1997 13:43:20 -0800
> X-Priority: 3
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.0.1458.49)
> X-Lines: 202
>
>
> I agree that it is possible to construct a scenario whereby
> case f) below is necessary. But isn't this a special case?,
> and if it is a gateway issue, I don't think this kind of text
> should be in the normative specification. We shouldn't
> preclude the construction of gateways, but we shouldn't
> necessarily sway the architecture or normative text
> directly towards supporting gateways.
>
> Perhaps, mechanisms that enable gateways should
> be an appendix...
>
>
> Also FYI,
> regarding cases (c) and (d) below, the latest
> TLS draft only provides authentication via certificates,
> and only certificates. These certificates contain
> (among other things) human readable identification strings.
>
>
> Randy
>
> > -----Original Message-----
> > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> > Sent: Wednesday, December 17, 1997 12:52 PM
> > To: Robert.Herriot@Eng.Sun.COM; rturner@sharplabs.com
> > Cc: hastings@cp10.es.xerox.com; ipp@pwg.org
> > Subject: Re: IPP>MOD Action Item from LA: fix
> > requesting-user-name explanation
> >
> >
> > > From rturner@sharplabs.com Wed Dec 17 00:38:33 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:
> > Change above two lines to:
> >
> > Each operation SHALL specify the user who is performing the operation
> > in both of the following 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.
> > Add the following sentence at the end of 1)
> >
> > 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
> > "guest".
> > > >
> > > > 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.
> >
> > I think that you are correct. Cases c and d are probably unnecessary.
> > I
> > have included them in case I am wrong.
> > >
> > > >
> > > > 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.
> >
> > Case f) is intended for a tightly coupled gateway and server to work
> > together so that the "user" name is that of the gateway's client and
> > not that of the gateway. Because most if not all system vendors will
> > initially implement IPP via a gateway into their existing print
> > system,
> > this mechansism is necessary unless the authentication mechanism
> > allows
> > a gateway (client) to act on behalf of some other client.
> >
> > >
> > > >
> > > > 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.
> >
> > I differ with you on the gateway case where I think that it
> > should be possible for a printer to be configured to treat
> > the requesting-user-name as the authenticated name. This
> > could happen for both TLS and for digest and basic
> > authentication.
> >
> > >
> > >
> > > 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.
> > >
> > You didn't comment on any of the above three lines. These differ from
> > the current model document by allowing the requesting-user-name or a
> > default guest name to be used for authorization.
>