-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of this API from a non-browser #11
Comments
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.
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.
The text was updated successfully, but these errors were encountered: