Smith,
I still need to finish updating the wiki for the last meeting's minutes... Anywsyd...
> On Nov 7, 2022, at 9:46 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> That sounds right - I couldn't remember how this played out and it doesn't seem to be covered in the wiki page.
>> However, I'm worried about that conclusion. If we advise that the Client supplies the "printer-uri" value as the resource identifier, wouldn't this mean that the Authentication Service needs to know the printer's current URI? That could be in the .local domain which isn't really any more useful or verifiable than a printer-uuid value. (Obviously how the printer and Authentication Service talk to one another is outside our scope of concern but that would affect whether the printer could register its URI with the Authentication Service.)
>> It seems like we could define the attribute but then provide guidance for how best to use it?
OK, so the subject of a "canonical" printer URI was something I've brought up as well.
From a standards-perspective the printer advertises its supported URIs, security mechanisms, and authentication methods, so the printer-uri-supported/uri-authentication-supported/uri-security-supported trio and printer/system-xri-supported collection attributes will indicate which URIs to use and which URIs support OAuth.
From a security standpoint, the same authentication and security (encryption) methods should be used/supported for all URIs, otherwise you are just creating "back doors". For interoperability you don't want to create a situation where a Client is confused about the URI, authentication, or security that it should use.
All that said, I don't think we can design or recommend a configuration where a Client can discover a Printer via mDNS, use a .local hostname, *and* use a cloud/remote OAuth authorization server with token exchange since there is no way to ensure that the printer-uri is globally unique.
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221108/5d3394e0/attachment.sig>