Closed samuelgoto closed 3 years ago
The other way we could go about this is with a registration API and double signed certificates, which would allow the browser mint new credentials. Something along the lines of:
navigator.registerEmailProvider((publicKey) => {
// publicKey is a new key that the browser generates that can be used
// to generate new assertions
return ...
});
A web-based email client would call that API and relying parties would call the WebOTP API to get new assertions minted:
let jwt = await navigator.credentials.get({transport: "email"});
And the JWT would contain two assertions:
1) one from the email provider delegating minting credentials to publicKey and 2) one from the publicKey, minting credentials tied to a specific origin / audience
WDYT?
Ok, I've written down more about this, so resolving this:
https://github.com/samuelgoto/email-otp
Lets follow up on that repo and have a discussion there.
There are a couple of ways I think this could go.
The first way, I'm thinking we would need some sort of convention with email providers (the same way we needed a convention for SMS messages).
It would seem we would need two parts:
(a) a machine-readable convention inside the email email with the OTP code and (b) some sort of browser API that allows an email provider to push/pull the OTP to/from the browser.
On (a), maybe something along the lines of a
meta
tag inside of the HTML email body would get the job done?On (b), something along the lines of browser API to push the code to the browser:
Or maybe an API that allows browsers to pull (maybe something like
/.well-known/one-time-code
?) as opposed to waiting for the push. For example:Responds with:
A website would call the WebOTP API passing the transport type =
email
to request it:Or declaratively:
WDYT?