samuelgoto
commented
8 months ago Just trying to capture this comment here in the PR, so that it doesn't fall through the cracks:
https://github.com/WICG/digital-credentials/pull/57#discussion_r1475960132
So, something that i think is a bit inconsistent with the CredentailsContainer but I think is actually good, is that the CredMan spec goes over in the Credential Registry the options member identifier, which is an WebIDL attribute that tells you which credential type to use.
await navigator.credentials.get({
publicKey: /** give me a passkey */,
otp: /** give me an SMS OTP */,
identity: /** give me a federated assertion */,
});Whereas providers here, would be for DigitalIdentity, but that seems like a general term that could apply to other Identity subclasses.
await navigator.identity.get({
providers: [] // what Identity interface do we expect to provide?
});For example, if we introduced a FederatedIdentity in the future, then we wouldn't know whether "digital" identities or "federated" identities are being requested.
So, this is a bit different from the navigator.credentials.get() API, but I'm not sure if it is necessarily bad.
It is hard to entirely predict the future, but I think the biggest differentiation in the subclasses of Identity is actually going to come as a result of introducing new protocols. That is, I think that the only distinction between a decentralized identity and a federated identity is the mechanism that defines how to request them.
That is, if/when we'd like to expose FedCM into this API, we could introduce a new protocol, add it to the registry in this spec here, and continuing returning a DigitalIdentity or, if necessary, create a subclass of Identity that is a FederatedIdentity, and the way we would figure out which one to construct is based on protocol, NOT the options member identifier as used in navigator.credentials.get().
I think this could work, but since it deviates from navigator.credentials.get() it seemed worth noting.
marcoscaceres
bvandersloot-mozilla
The CM spec's Extensions points outlines the following things to do to integrate. Adding as a todo list:
This document provides a generic, high-level API that’s meant to be extended with specific types of credentials that serve specific authentication needs. Doing so is, hopefully, straightforward.
For any such extension, we recommend getting in touch with public-webappsec@ for consultation and review.