-
Notifications
You must be signed in to change notification settings - Fork 36
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
How to define OtpCredential.id #11
Comments
I think I prefer option 1, wherein If you wish to provide other identifiers to a developer, you're hopping right out of the realm of OTP and into a broader set of questions and challenges. I'd suggest that keeping this API conceptually scoped to OTP is going to be both simpler to understand for developers, and simpler to reason about for privacy and security reviewers. :) I'm curious about the value of informing the developer about the transport over which the OTP was delivered. Won't they know how they went about sending the value to the user? Is there additional benefit to encoding that in the |
I was thinking that, in the future, we want to allow this API to allow multiple transports to be used at once (e.g. "fetch an OTP via either of these transport mechanisms"), and return just one (e.g. via email), so that the client can know where it came from. Something along the lines of: let {otp, transport} = navigator.credentials.get({otp: {transport: ["sms", "email"]}});
// transport == "email" WDYT?
I was thinking feature detection. Can you help me understand how else it could be done otherwise? if (window.OTPCredential) {
// ah, i can call navigator.credentials.get({otp: ...})
} else {
// ah, nevermind, i can't.
} |
Why does knowing where it came from matter? This might be obvious, but I'm missing it. :) If I send an OTP to you via 18 mechanisms, and you return whichever of those shows up first to me correctly, do I need to know which one you're giving me? It seems like the developer only cares that the OTP showed up, not that it showed up via mechanism 17 vs 13.
For this destructuring usage,
I think we're talking past each other. :) I absolutely think you want to have an I was questioning the value of the |
Earlier, Mike wrote:
I think the weirdness of possibly teaching folks to think of a “one-time code” as an “id” of some kind is a mistake. Imagine how confusing some of the resulting conversations could be. I think I would prefer |
Hey, Ricky, thanks for the feedback.
I imagine most conversations would go something like this: A: Hey, B. Do you know what I need to do to verify a user via SMS? :)
If I'm the only one who thinks that reusing
In this case, leaving |
That works for me too and I think was along the same lines others have suggested when I brought this up outside of this thread. I'm going to mark this as closed and resolve with the resolution to make OTPCredential use a string
I'll move the |
Just FYI, but tracking implementation on chrome here. |
Per conversation WICG#11 The spec has been updated to have a `code` field that will have the one-time-code and an undefined `id` field.
This issue is to talk about how we should define credential.id. There has been a few opinions that have come up which I've listed below but other options/opinions are welcome as well.
Option 1
Defining credential.id as OTP. This defines id as the user identifier from the the code distributor perspective and also removes the need to have a redundant otp field within credentials.
Option 2
Defining credential.id as undefined. However leaving the opportunity to let it be set to other user identifiers such as email addresses if in the future we add support to other transports like email OTP retrieval.
/cc @samuelgoto @sso-google @mikewest
Also please correct me if I've misstated something.
The text was updated successfully, but these errors were encountered: