[Sorry for the late response, trying to catch up on my email backlog...]
Smith,
So some feedback on the slides:
- Slide 6: We don't do TOFU for OAuth Printers (#3.2) and the Client does the Token Exchange with the auth server, not the printer (#6)
- 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
- 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)
- 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.
- Slide 11: So the Token Exchange spec isn't particularly clear, but the resource ID *is* the URI/URL for the resource. 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). And the X.509 fingerprint likewise isn't any help, not to mention short-lived certificates make scaling an issue.
- Slide 13: Self-signed is not trustworthy in this situation, ".local" certs depend on a trusted root (local certificate server and root cert)
- Slide 16: I don't think this is actually in question; from RFC 8693 (bold red added by me):
resource
OPTIONAL. A URI 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. 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, 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. The value of the resource parameter MUST be an absolute URI, 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.
> On Mar 30, 2023, at 4:43 PM, Kennedy, Smith Wireless & IPP Standards <smith.kennedy at hp.com> wrote:
>> Hi Mike and Piotr,
>> I was hoping to discuss this today but we obviously didn't get to it.
>> 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.
>> WDYT?
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>>> On Mar 27, 2023, at 10:28 PM, Kennedy, Smith Wireless & IPP Standards via ipp <ipp at pwg.org> wrote:
>>>> Signed PGP part
>> CAUTION: External Email
>>>> Hi there,
>>>> 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:
>>>>https://ftp.pwg.org/pub/pwg/ipp/slides/OAuth-2.0-Trust-Relationships-and-Resource-Identifiers-2023-03-27.pdf>>>> Cheers,
>>>> Smith
>>>> /**
>> Smith Kennedy
>> HP Inc.
>> */
>>>>>
________________________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20230411/17463d43/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/20230411/17463d43/attachment.sig>