Credential Management integration

[marcoscaceres]

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.

• [X] Define a new interface that inherits from Credential:

Define appropriate:

• [X] [[Create]](origin, options, sameOriginWithAncestors)

• [ ] [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors). [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) is appropriate for credentials that remain effective forever and can therefore simply be copied out of the credential store

• [ ] [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors). [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) is appropriate for credentials that need to be re-generated from a credential source.

• [ ] [[Store]](credential, sameOriginWithAncestors) methods on ExampleCredential's interface object.

• [ ] Long-running operations, like those in PublicKeyCredential's [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations are encouraged to use options.signal to allow developers to abort the operation. See DOM §3.3 Using AbortController and AbortSignal objects in APIs for detailed instructions.

• [ ] ExampleCredential's [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) internal method is called with an origin (origin), a CredentialRequestOptions object (options), and a boolean which is true iff the calling context is same-origin with its ancestors. The algorithm returns a set of Credential objects that match the options provided. If no matching Credential objects are available, the returned set will be empty.

• [x] Define the value of the ExampleCredential interface object's [[type]] slot:

• [ ] Define the value of the ExampleCredential interface object's [[discovery]] slot:

• [ ] Extend (using partial dictionary) CredentialRequestOptions with the options the new credential type needs to respond reasonably to get().

• [ ] Extend (using partial dictionary) CredentialCreationOptions with the data the new credential type needs to create Credential objects in response to create().

You might also find that new primitives are necessary. For instance, you might want to return many Credential objects rather than just one in some sort of complicated, multi-factor sign-in process. That might be accomplished in a generic fashion by adding a getAll() method to CredentialsContainer which returned a sequence<Credential>, and defining a reasonable mechanism for dealing with requesting credentials of distinct types.

For any such extension, we recommend getting in touch with [public-webappsec@](mailto:[email protected]) for consultation and review.

[samuelgoto]

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.

[samuelgoto]

Taking notes here:

• we'll use the default implementations of [[Create]] and [[Store]], which returns null and throwsNotSupportedError respectively.
• we need to define [[type]] to return digital
• we need to define [[discovery]] as remote
• we need to define [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
• register the extension here
• Abort Signals: we need to specify an abort algorithm

Separately, we'd need to change the Credential Manager spec to:

• allow more than one instance of CredentialsContainer to exist (under navigator.credentials and navigator.identity) and have their algorithms get the right container and interface types.

[marcoscaceres]

Adding that we need to deal with iframes as part of this: https://github.com/WICG/digital-identities/issues/78

[bvandersloot-mozilla]

I was imagining something more in parallel to the structure of the navigator.credentials call. Is it preferable to make FedCM and DigitalCredential, both Credentials in the navigator.identity registry, to enable parsing their config options? That allows non-"providers" fields in the requestoptions, which already exists (!) in FedCM (https://fedidcg.github.io/FedCM/#enumdef-identitycredentialrequestoptionscontext).

[samuelgoto]

Is it preferable to make FedCM and DigitalCredential, both Credentials in the navigator.identity registry, to enable parsing their config options?

I was thinking that if, and ever, we expose the two party model (i.e. FedCM) into navigator.identity, we would allow ourselves to create a new credential type while leaving the IdentityCredential to the navigator.credentials namespace to refer to auth-like credentials. WDYT?