Hi Pete et al,
Please find our comments/suggestions below.
Comments:
1. Page 22: "Printer-current-time" should be "printer-current-time"
a. Some comments about how a 'IPP over USB' only scanner that does not have an RTC chip should consider implementing this and other 'date-time' values (which are mandatory now) will be useful.
2. Line 883/884 [Page 50]: The values for 'uuid'. Is the USB serial number truly globally unique? Isn't its uniqueness scope typically limited to devices using the same PID & same VID? Typically, it is the host operating system that generates a UUID for the device to identify the device internally. IMO, it'll be better to say "This value should be the same value as 'printer-uuid' attribute in the scan service itself (which is also the value that 'IPP over USB' will use)". This will help us have a consistent (printer generated) UUID value across IPP devices.
3. Section 4.1.7: 'file' URIs that could point to local hard-drives/thumb-drives/memory cards in the printer as the destination are one class of storage that have been left out. Of course, 'destination-uri-schemes-supported' (Section 8.4.2) seems to be open ended about the URI schemes. Are both of these intentional?
4. This could be a topic for the implementer's guide; but can be addressed in the specification too: While we are mostly not concerned about products that choose the most secure channel for communicating with the device, we may want to briefly touch vulnerability as the stakes are higher with new operation attributes related to credentials to access third party services have been introduced in IPP Scan. Further since these may not be sufficiently covered by the security considerations of RFC2911, it may be safer to discuss the vulnerability aspect of these, just in case it is not obvious to the implementers. We could do one of the three below. Only 4.a is a secure method. 4.b is sufficiently addresses security of credentials if the client is properly implemented and if certification processes ensure that. 4.c is purely a warning to the developer.
a. By specification, make encryption (IPPS) mandatory for Scan (either always or at least, if credentials are required): I know that this is a little heavy handed and may not be well liked; but 'IPP Scan' does not have any legacy support to worry about.
b. Advertise those destination-uri that REQUIREs credentials only if the request came in through a secure channel (https or USB) and not if the request came through an unsecure channel (http and not USB). One implementation concern here is some web-servers may not convey information about the secureness of the channel to the application layer; but not something insurmountable. This also means that unsecure IPP will be a reduced function set compared to the secure IPPS. While this duality may make some uncomfortable, this is a very pragmatic way to keep user information safe.
c. Make comments about the vulnerability in exposing credentials through IPP (instead of IPPS)
5. Comments regarding access-oauth-token: OAuth2 tokens are closely associated with an authorisation service (a.k.a. auth server) and one or more authorisation scopes (a.k.a auth_scope). The specification does not make either of those information explicit. When using the current specification, the 'IPP Scan client' and the 'applications hosted through IPP Scan server' need to be developed closely together as both the auth server and the auth scope are implicit. The destination-uri itself may not be sufficient to decide which OAuth2 server needs to be contacted and which auth_scope needs to be used when getting the user's authorization to access a service on the user's behalf. Of course, for some well-known web-services, this information may be well known; but still, there could be applications in the IPP Scan server that make use of more than one auth scope to complete their workflow and the server does not seem to have a way to specify the required auth scopes even when working with a well-known web-service. So, I would like to propose the following new attributes that can be used by the IPP Scan server as a part of Scan2 destination discovery using 'destination-uri-ready'. Please find the proposal below.
Proposal for new attributes to destination-uri-ready
If destination-uri-ready can take additional member attributes to allow the system to specify the OAuth URL that the scan client needs to contact and the auth scope that the authorisation should be requested for, the scan client may be able to try to start the OAuth2 flow by connecting to the OAuth URL (and specifying the auth scope in the process), finish the OAuth2 process and get the OAuth2 access token for accessing the service that the device wants the access token for. For that, I would like to propose an optional attribute that is part of a destination-uri-ready.
destination-uri-ready
destination-uri
. . .
[destination-oauth-descriptor (collection)]
[destination-oauth-uri (uri)]
destination-oauth-scope (1setOf text(MAX))
destination-oauth-uri, for example, can specify https://accounts.google.com/o/oauth2/auth to indicate that Google's OAuth server is the server that is expected to issue the OAuth2 access tokens for this destination. This can still be optional if the destination is considered to be a well-known server and/or if the MFD/Scanner does not want to specify this for a destination that only the OEM's clients/servers should support. However, having this option will be useful as the scan client does not have to try to interpret "destination-uri". This also allows "destination-uri" to have a shortened URL or the destination-uri may point to a service that makes use of an external service for authorization/authentication like Google for authorization (imagine something like OpenID or even simply OAuth2).
destination-oauth-scope will specify one or more auth scopes that the MFD needs access to in order for it to complete the workflow. Since not all auth scopes look like URIs. So, this is a text type.
Thanks and Regards,
Somasundaram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140714/65cf3723/attachment.html>