Re: Add "oauth-authorization-resource" attribute?

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]> Wed, 9 Nov 2022 04:56:53 +0000
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Hi Mike,

> On Nov 8, 2022, at 4:27 AM, Michael Sweet <[email protected]> wrote:
> 
> CAUTION: External Email
> 
> From: Michael Sweet <[email protected]>
> Subject: Re: [IPP] Add "oauth-authorization-resource" attribute?
> Date: November 8, 2022 at 4:27:43 AM MST
> To: "Kennedy, Smith (Wireless & IPP Standards)" <[email protected]>
> Cc: PWG IPP Workgroup <[email protected]>
> 
> 
> 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) <[email protected]> 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).

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)