Comment 9 for bug 735297

So, here's what happened:

CUPS receives job to print, fires up smb backend to print it
smb backend communicates with server, server requires password
We don't have one, so smb backend stops, telling cupsd why
cupsd marks the job as requiring authentication
At this point, CUPS knows that "username,password" is required for jobs to this queue so it adds that attribute to the printer configuration.
s-c-printer-applet sees the job has stopped and requires auth, so displays an authentication dialog
Once received from user, the applet uses IPP-Authenticate-Job to restart the job

Now, for future jobs, CUPS will actually refuse to queue the job unless it is accompanies by "username,password"-type auth-info. It already knows, from past experience, that a username and password will be required.

So now it is up to the application that talks to CUPS to provide the username and password.

Conveniently, s-c-printer-applet stored the user's credentials (if they chose to) in the GNOME keyring, so you can look it up there. Alternatively, the application has to make its own arrangements e.g. presenting another auth dialog at that point.