How to define OtpCredential.id

[wicg]

How to define OtpCredential.id

[rmondello]

Earlier, Mike wrote:

I think I prefer option 1, wherein OTPCredential is an empty subclass of Credential, and the credential's identifier is the OTP code. An empty id feels strange. (That said, I grant that accessing an id attribute to get the code you want is also strange. :) )

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 OTPCredential to be a nearly-empty subclass of Credential, with tacks on a String code property. The ergonomics and cognitive dissonance in the API is greatly reduced by this. If we did this, presumably the id of such an OTPCredential would be undefined.

[mikewest]

I think I prefer option 1, wherein OTPCredential is an empty subclass of Credential, and the credential's identifier is the OTP code. An empty id feels strange. (That said, I grant that accessing an id attribute to get the code you want is also strange. :) )

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 OTPCredential object as well?

[samuelgoto]

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?

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?

Is there additional benefit to encoding that in the OTPCredential object as well?

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.
}

[mikewest]

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

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.

let {otp, transport} = navigator.credentials.get({otp: {transport: ["sms", "email"]}});

For this destructuring usage, otp makes more sense than id. But I still don't think an empty ID makes sense. Perhaps we can have both, and simply alias one to the other?

I was thinking feature detection. Can you help me understand how else it could be done otherwise?

I think we're talking past each other. :) I absolutely think you want to have an OTPCredential interface. As you note (and as the spec notes in https://w3c.github.io/webappsec-credential-management/#implementation-authors), checking for the presence of that interface is a great way to feature-detect capabiilty.

I was questioning the value of the transport member on OTPCredential, as discussed briefly above.

[mikewest]

Hey, Ricky, thanks for the feedback.

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 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?
B: Yeah, copy/paste this snippet from StackOverflow.
A: Thanks! I'll do that! Hooray!

:)

I think I would prefer OTPCredential to be a nearly-empty subclass of Credential, with tacks on a String code property.

If I'm the only one who thinks that reusing id is sane, so be it. It feels pretty reasonable to me to consider the code delivered from the server as an identifier, but if y'all would prefer to call it a "code" instead, I'm totally fine with something like:

interface OTPCredential : Credential {
  readonly attribute DOMString code;
}

In this case, leaving id as undefined is probably reasonable (though I'd reiterate my claim from earlier that I'm not terribly excited about potentially filling the id with some other user identifier in the future).

[samuelgoto]

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 code and leave id undefined.

interface OTPCredential : Credential {
  readonly attribute DOMString code;
}

I'll move the transport discussion here, and leave this issue to discuss specifically between id vs code to contain the OTP value.

[samuelgoto]

Just FYI, but tracking implementation on chrome here.