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.