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.)
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.
> 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.
> Bill Wagner
>>> -----Original Message-----
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Monday, July 15, 2013 4:25 PM
> To: cloud at pwg.org> Subject: [Cloud] Minutes posted from today's Cloud Imaging WG conference call
>> 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>> 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
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud
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...