Hi Randy,
1. Since it was decided that a Cloud Imaging Service could be
associated with more than one device, we had to model a way to register a
Device service with a pre-existing Cloud Service. There seemed no advantage
in also modeling a mode where registering a device created the Cloud
imaging service.
2. It was maintained that a device owner may not want to register all
capabilities of a device. He may want to restrict registration to specific
services or even elements of specific services. Therefore, the model should
(and does) accommodate this.
a. If a device owner wishes to register all parts of all services of a
device with the corresponding services of a Cloud Imaging System, all he
need do is inform the Proxy of the local device (if the proxy handles more
than one) and the Cloud Imaging System. The Update System Elements and
Update Service Elements operations are ones the Proxy needs to exercised
once registration is complete anyway and, if the Proxy/Device interface is
semantic model compatible (e.g. IPP), the Proxy easily obtains the
information in these operations (as well as the List Services) by existing
interface operations. I doubt that from the Owners viewpoint that it could
be simpler.
b. If the Owner wishes to limit what Device and/or Service elements he
is registering, the registering application would list the Device and
Service elements to allow the Owner to flag what should not be made
accessible to the Cloud System.
3. Outlining a UI is out of scope for the spec, but I could envision
something like the following:
a. Owner connects to the Proxy. Proxy returns identification of
devices it supports and requests desired action. User indicates
Registration with Cloud Imaging System
b. Proxy requests address of Cloud Imaging System and the ID of the
Devices to be registered. User provides this (plus security access info if
needed)
c. Proxy contacts Cloud Imaging System and (if successful) returns to
User the basic characteristics of the Cloud Imaging System, including
supported Cloud Imaging Services. It also lists the Services in each of the
devices to be registered and asks that the Owner identify which device
services are to be associated with which Cloud Imaging Services. There is a
'default' choice which, in a simple case, merely associates each device
service with each corresponding Cloud Imaging Service. Alternately, the
Owner may show an A-A, B-B, D-D relation, omitting Device Services that are
not to be made accessible.
d. Proxy then asks if there are Service elements that are not to be
made accessible (reasonably listing typical elements for each service that
may reasonable be limited) . Owner can answer NO, or he can mark what is not
to be made accessible. He is done.
e. Between this interchange and its communication with the device,
Proxy has all it needs to complete the registration.
4. Indeed, we fully intend to pass the registration sequence, the
normal Proxy/Cloud Service communication, the User /Cloud Service
Communication, the access by reference operations, and various
administrative interactions to IDS for security issue consideration.
5. I would expect the Transaction-Based Printing Extensions
(previously Paid Printing) to reflect back into the Network Printing
interface of the Semantic Model, and therefore into the Client/Service
interaction of Cloud Imaging. The User submits a Job request to the Cloud
Service. That service will need to consider the Users authorization (based
on who they are, where they connect from, how good their credit is,
whatever) to use both the Cloud Service and the desired features of the end
device. The end device (through the Proxy) needs to report on the work done
in conjunction with the resulting job, and we will need to consider what
additional elements need to be included in the Cloud Service/Proxy
interface. But I expect that the device does not get into authorization
beyond what is necessary to obtain local user identification information
(e.g., PIN, biometric data, etc) and send it to the Cloud Service.
Thanks,
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Friday, July 19, 2013 10:05 PM
To: <cloud at pwg.org>
Subject: Re: [Cloud] Minutes posted from today's Cloud Imaging WG conference
call
Hi Bill,
RE: Item #1 below, starting with "The Device Owner." , it seems like a
complicated interface and sequence of steps that the owner will have to take
to register his device for cloud access. If I'm doing one imaging device,
it might seem tractable. If I'm doing 20 or 30 heterogeneous devices, it
seems excessive. Have we modeled how this might look for an administrator,
like what would the UI look like, or what the admin experience would be?
>From Note 1b, I thought registration "caused" a corresponding cloud imaging
service to be created? The device registers with some generic
(non-specific) imaging cloud service, correct? and then once registered, the
"corresponding" service is created. Or at least that's what I thought we
were talking about at the last face-to-face.
Also, from your "Note #2 below", It seems reasonable that the
"Authorization" part of the cloud service is probably out of scope for the
Cloud WG.but you've highlighted some examples of potential predicates for an
authorization decision -- if anyone has any ideas regarding the types of
authorization decisions that a service might want to make, I would urge the
group to pass those along to the IDS team, especially whoever has the ball
on a XACML dialect for imaging authorization.
I know that Mike has published the "Paid Extensions" stuff from IPP that
uses some type of authorization ticket that says "I've paid for what I'm
asking for", but I would hope that this type of authorization would be just
another predicate check by a larger, overall authorization engine, and that
there would be one (and only one) "Ok, we'll allow this operation" ticket or
token that takes into account all authorization decisions (predicates,
conditions, etc.)
R.
On Jul 19, 2013, at 4:29 PM, William A Wagner <wamwagner at comcast.net> wrote:
As I generate a Registration section for the Cloud Imaging Model, I would
like to verify my understanding of the decisions made at Monday's meeting.
1. The Device Owner, operating through the Cloud Imaging Device Proxy that
provides the cloud interface for the device, registers the device and the
device services he wishes to make available to the Cloud Imaging System. He
may desire to block access to specific Device elements and Service elements.
In response to information provided by the Device owner to the Proxy:
a. The proxy provides Device registration information with an initial
Update System Elements message to the Cloud System Control Service. This
message provides information on all System Elements of the Device that are
to be made known to the Cloud Imaging System. It corresponds to a response
to a current Get System Elements message with all elements identified.
b. The Proxy identifies the Device Services that are to be accessible to
the Cloud Imaging System by sending an Identify Services message to the
Cloud System Control Service. This corresponds to a response to a current
List Services operation.
c. The proxy identifies the elements of each Device Imaging Service that
are to be made available to the corresponding Cloud Imaging Service by
sending an initial Update Service Elements to an Owner-identified
corresponding imaging service of the target Cloud Imaging System. This
corresponds to a response to a current Get Service Elements operation.
2. Once Device and Service registrations are complete, the Proxy will
maintain contact with the Cloud System Control Service and the registered
Imaging services, updating System and Service Elements and checking Cloud
Imaging Services for jobs.
Note:
1. It was decided that:
a. Devices and Service are registered, not subunits
b. Device Services can only be registered with corresponding Cloud Imaging
Services
c. Therefore: a Device subunit cannot be made accessible to a Cloud Imaging
Service unless that subunit is configured as part of a Device Imaging
Service that is registered with the Cloud Imaging Service. For example, a
Cloud FaxIn Service can not use a marking engine in a Print Device unless
that marking engine is also configured as part of a FaxIn service that is
registered with the Cloud FaxIn Service. (This seems an unfortunate
limitation to me.)
2. It was agreed that the Owner will want to place restrictions on:
a. Who can use the device, with respect to one or more of the following:
i. User ID, possibly including results of
authentication
ii. Geographical or network typological origin of
the user
iii. Payment or credit
iv. Any one of various other conditions
b. What services a user can use
c. When each user can use what services (e.g., Print and Hardcopy Fax and
Email only during working hours; FaxIn, EmailIn to storage all the time)
d. Degree of use (e.g., max number of copies)for each particular user and
Service
e. Probably other conditions
The owner will communicate with the Cloud Imaging System with an "access
list" to identify these User rights and restrictions. This process is out of
scope for the Cloud Imaging Model.
I would appreciate confirmation or correction of this understanding.
Thanks,
Bill Wagner
-----Original Message-----
From: <mailto:cloud-bounces at pwg.org> cloud-bounces at pwg.org [mailto:cloud-
<mailto:bounces at pwg.org> bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Monday, July 15, 2013 4:25 PM
To: <mailto:cloud at pwg.org> cloud at pwg.org
Subject: [Cloud] Minutes posted from today's Cloud Imaging WG conference
call
All,
I have posted the minutes to today's Cloud Imaging WG conference call to:
<ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20130715.pdf>
ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20130715.pdf
Our next conference call will be on July 29, 2013 at 3pm ET.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
_______________________________________________
cloud mailing list
<mailto:cloud at pwg.org> cloud at pwg.org
<https://www.pwg.org/mailman/listinfo/cloud>
https://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean. _______________________________________________
cloud mailing list
<mailto:cloud at pwg.org> cloud at pwg.org
<https://www.pwg.org/mailman/listinfo/cloud>
https://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130720/804ddcf6/attachment-0002.html>