dlongley
commented
4 years ago As this is an HTTP-based API, I would expect this to work for any arbitrary clients and not be restricted to browsers (and service workers) only.
So far, implementations have only supported a JavaScript API. When using a browser, the API allows requests for credentials/requests to store credentials to be passed via a JS API through a "mediator" (the browser) to a Credential Handler provided by another website. The Credential Handler typically receives these requests via JS events and responds via JS.
I would expect this to work for any arbitrary clients and not be restricted to browsers (and service workers) only.
Yes, there is space for a Credential Handler to send its response to the mediator in another way (perhaps involving HTTP or Web RTC), thereby enabling native (non-browser) Credential Handlers. This has yet to be spec'd out as there has not been a native Credential Handler implementer that has expressed interest in doing an experimental implementation yet.
We'd love to see a native Credential Handler implementer come forward to discuss possible designs that might work for them and offer to do an experimental implementation. In order to integrate a native Credential Handler (CH) with the browser polyfill, concepts have been floated involving running an ice/stun server on the polyfill mediator site and using WebRTC to communicate responses from the native CH to the mediator so that they can be forwarded onto the relying party website whilst maintaining consistent UX.
As this is an HTTP-based API, I would expect this to work for any arbitrary clients and not be restricted to browsers (and service workers) only.