Mike/Pete,
Thank you very much for your response.
I wanted to follow-up on that as it appeared 'authentication for destination' wasn't addressed for FaxOut/Scan2 destinations while those IPP/http destinations may require authentication. So, wanted to understand what all of you think about that.
I am certainly not a fan of passing down credentials unless the client sends OTP over a secure connection. Of course, there is always a risk of a fake service.
It helps to know that dealing with authentication for destination was consciously left 'undefined'. And thanks for letting me know that the current HTTP URI scheme "forbids" the use of embedding credentials in the URI. So, it appears that MFDs do not have to necessarily add support for credentials in the 'http' destination-uri after all as the standards do not allow that technical possibility.
Thanks and Regards,
Somasundaram.
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Wednesday, April 09, 2014 8:19 PM
To: Soma Meiyappan
Cc: Peter Zehler; IPP at pwg.org
Subject: Re: [IPP] Are these attributes what were agreed to for IPP Scan?
Soma,
On Apr 9, 2014, at 12:13 AM, Soma Meiyappan <Soma.Meiyappan at conexant.com<mailto:Soma.Meiyappan at conexant.com>> wrote:
Mike/Pete,
May I know how PWG solves supporting IPP destinations (and other HTTP destinations) that need authentication when used as a destination in FaxOut/Scan2 defined workflows?
It is currently undefined at the protocol level (meaning that it is up to each implementation to do something about it), just as how to deal with authentication of document URIs is at present.
This is pending work in the IDS workgroup. CUPS has the "auth-info" and "auth-info-required" attributes, as well as a job-state-reasons keyword and IPP operation as extensions to IPP for dealing with authentication for a printer's output device (usually another computer/server that is sharing a print queue), but there are practical limitations to the approach.
Are authentication information for URIs under destination-uri-ready (implicitly) managed by the MFD as it appears that the specification does not provide any destination specific attributes in the destination-uri collection to provide authentication credentials? Or should authentication information be provided in the URI as it is done for some http URI allows like http://user:passwd@mystoragedrive.com/folder? If so, I would wonder about IPP destinations and ipp/ipps URIs.
Embedding user credentials in HTTP and IPP URIs is not recommended, and in fact the current HTTP and IPP URI scheme definitions forbid it.
(FWIW, CUPS also supports this kind of authentication for the output device URI, but we've had to go through a lot of hoops over the years to hide the information from prying eyes. Definitely not recommended!)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140409/8d33ccf2/attachment.html>