attachment
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Mike,<div><br></div><div>Slides updated a bit with your feedback:</div><div><br></div><div> <a href="https://ftp.pwg.org/pub/pwg/ipp/slides/OAuth-2.0-Trust-Relationships-and-Resource-Identifiers-2023-04-11.pdf">https://ftp.pwg.org/pub/pwg/ipp/slides/OAuth-2.0-Trust-Relationships-and-Resource-Identifiers-2023-04-11.pdf</a> </div><div><br></div><div>Sorry, lots of comments below. Can discuss more via email or we can wait till Thursday.</div><div><br></div><div>Smith</div><div><br><div>
<div><br><blockquote type="cite"><div>On Apr 11, 2023, at 7:41 AM, Michael Sweet <msweet@msweet.org> wrote:</div><br class="Apple-interchange-newline"><div>CAUTION: External Email<br><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);"><b>From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Michael Sweet <msweet@msweet.org><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);"><b>Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b>Re: [IPP] Updated "OAuth 2.0 Updates: Trust Analysis and Resource Identifiers" slides posted</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);"><b>Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">April 11, 2023 at 7:41:21 AM MDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">"Kennedy, Smith Wireless & IPP Standards" <smith.kennedy@hp.com><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);"><b>Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">PWG IPP Workgroup <ipp@pwg.org>, Piotr Pawliczek <pawliczek@google.com><br></span></div><br><br><meta http-equiv="content-type" content="text/html; charset=us-ascii"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>[Sorry for the late response, trying to catch up on my email backlog...]</div><div><br></div>Smith,<br><br>So some feedback on the slides:<div><br></div><div>- Slide 6: We don't do TOFU for OAuth Printers (#3.2)</div></div></div></blockquote><div><br></div><div>I know you and Piotr have arrived at this position but I haven't joined you there yet. 😊 </div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div> and the Client does the Token Exchange with the auth server, not the printer (#6)</div></div></div></blockquote><div><br></div><div>Yes...but the arcing #6 arrow is trying to illustrate the trust relationship that the device access token is trying to provide: (a) to have an artifact that can be used for #7, and (b) to validate the relationship between the Authentication Service and the Printer. Do you disagree with what I have in the "Mechanism" and "Comments" cells of Row 6 on slide 7? </div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>- Slide 7: We don't do TOFU for OAuth Printers - this does not scale and is not trustworthy, resource identifier is printer URI so the trust depends on the hostname being unique (within the authorization framework/domain used) and TLS cert validation working</div></div></div></blockquote><div><br></div>I guess we will continue to discuss this in the meeting. It seems you (and perhaps Piotr) have decided that OAuth 2.0 authenticated local printing is impossible in the absence of a globally unique FQDN. I am still looking for a way to accommodate devices that are behind an IPv4 NAT with no globally unique FQDN, to satisfy Use Case #3 on slide 2. </div><div><br></div><div>The JWE and Fingerprint Resource Identifier options seemed like a pathway to support this, by accepting a reduced level of trust in the printer's certificate but using Token Exchange to validate that the Authentication Service can vouch for the identity of the printer because of the quality of the Resource Identifier. (This does depend on the Client fully trusting the Authentication Service, however. If both the printer and the Authentication Service are malicious then the Client is in trouble...how does OAuth 2.0 deal with that?)</div><div><br></div><div><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>- Slide 8: Again, we've already talked about TOFU and decided we don't allow it with OAuth because it is *not* trustworthy/scalable. The "quality" of the resource ID is the uniqueness of the printer URI (the URI the Client is using to connect to the printer, and thus the *resource* being used/authorized).</div></div></div></blockquote><div><br></div>I'm not questioning the utility or the quality of the globally routable FQDN / printer URI solution, and I'm not trying to reject it. My position is that the globally routable FQDN / printer URI solution does not satisfy all the use cases that I and my colleagues at HP believe need to be supported, and I'm trying to find alternatives to close that gap.</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>- Slide 9: The resource ID is not cryptographically signed, so there is no question of trustworthiness. If the hostname in the URI is unique, the TLS cert validation provides the guarantee/trustworthiness of the resource ID and the token exchange ensures that the printer is registered with the auth server. Thus, the key is NOT the resource ID/URI but the X.509 certificate used by the printer.</div></div></div></blockquote><div><br></div>I'm sorry but I'm not quite following what you are saying above about slide 9.</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>- Slide 11: So the Token Exchange spec isn't particularly clear, but the resource ID *is* the URI/URL for the resource.</div></div></div></blockquote><div><br></div>You referenced RFC 8693 and cited section 2.1's definition of "resource" below, which specifies that the resource MUST be an absolute URI, which typically is an https URL, but doesn't have to be.</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div> For IPP that probably means the https equivalent URL as specified in RFC 7472 (ipps URI scheme). JWE doesn't help because you need to use a client-supplied secret to demonstrate ownership of the private key (necessary to prevent MITM attacks).</div></div></div></blockquote><div><br></div><div>By "client" do you mean the IPP Client? And what "private key" are you talking about in this context?</div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div> And the X.509 fingerprint likewise isn't any help, not to mention short-lived certificates make scaling an issue.</div></div></div></blockquote><div><br></div><div>Unless I am mistaken, the fingerprint of an X.509 certificate is unique for each certificate. If the Printer registers the fingerprint of its current TLS certificate (CA-issued or self-signed) with the Authentication Service, and the Client uses the fingerprint of the printer's X.509 TLS certificate as the Resource Identifier, and the Authentication Service returns an Access Token, then why is the Client unable to have confidence that the Authentication Service and the Printer have a relationship with one another, and by extension that the Printer can better trust the Printer? </div><div><br></div><div>If I'm not mistaken, this idea was originally suggested by Piotr last year. Piotr - any comments on this?</div><div><br></div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>- Slide 13: Self-signed is not trustworthy in this situation, ".local" certs depend on a trusted root (local certificate server and root cert)</div><div><br></div><div>- Slide 16: I don't think this is actually in question; from RFC 8693 (bold red added by me):</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>resource</div></div><div><div><br></div></div><div><div>OPTIONAL. <b><font color="#ff2600">A URI</font></b> that indicates the target service or resource where the client intends to use the requested security token. This enables the authorization server to apply policy as appropriate for the target, such as determining the type and content of the token to be issued or if and how the token is to be encrypted. In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know a URI of the service where it intends to use the token. <b><font color="#ff2600">The resource parameter allows the client to indicate to the authorization server where it intends to use the issued token by providing the location, typically as an https URL</font></b>, in the token exchange request in the same form that will be used to access that resource. The authorization server will typically have the capability to map from a resource URI value to an appropriate policy. <b><font color="#ff2600">The value of the resource parameter MUST be an absolute URI</font></b>, as specified by Section 4.3 of [RFC3986], that MAY include a query component and MUST NOT include a fragment component. Multiple resource parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. See [OAUTH-RESOURCE] for additional background and uses of the resource parameter.</div></div></blockquote></div></div></blockquote><div><br></div>Thanks for the citation. 😊 That helps.</div><div><br></div><div>But I think I must have not conveyed my point clearly because I think you misunderstood what I was trying to convey. My point was that the Authentication Service may support only one of the types listed on slide 11. Unless we concur to stand pat with only global FQDN / CA-issued cert / printer-URI, the Client will need a way to discover what resource identifier value to provide to the Authentication Service.</div><div> <br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div><br><blockquote type="cite">On Mar 30, 2023, at 4:43 PM, Kennedy, Smith Wireless & IPP Standards <smith.kennedy@hp.com> wrote:<br><br class="Apple-interchange-newline">Hi Mike and Piotr,<br><br>I was hoping to discuss this today but we obviously didn't get to it.<br><br>What are your thoughts about this deck? In particular, you think that implementing Piotr's old idea about using the printer's TLS certificate SHA-256 fingerprint as the Resource Identifier is reasonable or is impractical? It would require the printer to register its certificate or fingerprint with the Authentication Service but that shouldn't seem onerous. It would open the way to supporting self-signed certificates.<br><br>WDYT?<br><br>Smith<br><br>/**<br> Smith Kennedy<br> HP Inc.<br>*/<br><br><blockquote type="cite">On Mar 27, 2023, at 10:28 PM, Kennedy, Smith Wireless & IPP Standards via ipp <ipp@pwg.org> wrote:<br><br>Signed PGP part<br>CAUTION: External Email<br><br>Hi there,<br><br>I've posted a new "OAuth 2.0 Updates: Trust Analysis and Resource Identifiers" deck with updates that I'd like to discuss at the next IPP WG meeting. The slides are here:<br><br>https://ftp.pwg.org/pub/pwg/ipp/slides/OAuth-2.0-Trust-Relationships-and-Resource-Identifiers-2023-03-27.pdf<br><br>Cheers,<br><br>Smith<br><br>/**<br> Smith Kennedy<br> HP Inc.<br>*/<br><br><br></blockquote><br></blockquote><br><div>
________________________<br>Michael Sweet<br>
</div>
<br></div></div><br><br></div></blockquote></div><br></div></div></body></html>