Smith,
> On Dec 15, 2022, at 11:32 AM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> ...
>> You can't send a fingerprint from the Client to the Authorization Server (AS) because a) there isn't a protocol for that
>> I wondered about that when Piotr mentioned it before since the token exchange doesn't have a parameter specifically for it. I was thinking that we could do something gross like provide a URI instead of just a hostname for the resource parameter to token exchange endpoint, and embed the fingerprint in the URI. It seems like we might need to send a URI anyway since the print server may host more than one printer, and the token exchange ought to target a specific printer, not just a "host". But this is veering into questionable terrain.
Agreed.
>> and b) even if you did there is no way for the AS to authenticate the fingerprint (i.e. the resource URI is the only information it has about the printer that is the same as what the Client sees, the AS may never see the Printer's X.509 certificate...)
>> I thought about that too - ideally the registration process would provision the printer with a certificate issued by the same CA as the Authentication Service and have other fields that the Client could use to indicate the printer's connection to the Authentication Service's control space / domain / ecosystem / whatever. Alternately, the Authentication Service would be given the printer's certificate (possibly self-signed), but that is weaker in a few ways.
>> If the Authentication Service has no knowledge of the printer's certificate, then a bunch of this is even weaker from a trust establishment point of view.
I think it will be fairly common for the AS, the Printer, and (when applicable) the Infrastructure Printer to have certificates using different roots of trust. In fact, the only time they will use the same CA is in enterprise networks that provide their own private AS, CA, etc.
For a public OpenID service, the operator of that service will use a random public CA. The Infra Printer and Printer will likely use different random CAs, with the Printer/Peoxy possibly sharing a root with the Infra Printer (as is the case with Azure Universal Print Service instances), although in the Infra case the Client will be talking to the Infra Printer so the Printer/Proxy's certificate doesn't matter for OAuth.
________________________
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/20221215/3c15599f/attachment.sig>