Hi Mike,
> On Nov 8, 2022, at 4:27 AM, Michael Sweet <msweet at msweet.org> wrote:
>> CAUTION: External Email
>> From: Michael Sweet <msweet at msweet.org>
> Subject: Re: [IPP] Add "oauth-authorization-resource" attribute?
> Date: November 8, 2022 at 4:27:43 AM MST
> To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com>
> Cc: PWG IPP Workgroup <ipp at pwg.org>
>>> 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.
If an Authentication Service supports a certificate or some other more trustable artifact as a resource identifier, perhaps one provisioned to the printer at the time the printer is registered, that could improve the situation, right? I thought we discussed that at the August F2F.
Regardless, I think that it would be better for the client to use the value provided by a purpose-defined but abstract attribute like "oauth-authorization-resource-id" instead of instructing or guiding clients to use "printer-uuid" or "printer-uri". The value held by "oauth-authorization-resource-id" could be a URI or a UUID (printer-uuid or some other UUID).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221109/9610aff1/attachment.html>
-------------- 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/20221109/9610aff1/attachment.sig>