FedCM IdP error responses

[panva]

Currently the IdP has no way to return errors back to FedCM from neither the id_assertion_endpoint nor from within the Continuation API popup.

The only fulfillable response from is 200 OK that matches IdentityProviderToken from the endpoint or IdentityProvider.resolve from the Continuation API popup.

I believe there should be an error format specified, such as one that allows a 400-499 status code range and fields (conveniently borrowed format from OAuth) that would fulfill the RP's credential.get(), likely with a rejection?

dictionary IdentityProviderError {
  required USVString error;
  USVString error_description;
  USVString error_uri;
};

The Continuation API version of this, used e.g. when the end-user clicks on "cancel" / "abort" in the IdP prompt.

IdentityProvider.reject(<IdentityProviderError>data);

The rejection should allow discerning between IdP errors and FedCM errors, such as with specific Error subclasses FedCMIdentityProviderError so that the client can make a call such as

const credential = await navigator.credentials.get({
  // ...
}).catch((err) => {
  if (err instanceof FedCMIdentityProviderError) {
    console.error(err.message) // generic message that the IdP returned error
    console.error(err.details) // IdentityProviderError
    console.error(err.details.error) // e.g. access_denied
    console.error(err.details.error_description) // e.g. End-User aborted the flow (ERR 372)
    console.error(err.details.error_uri) // e.g. https://docs.idp/errors#explain-372
  }

  throw err
});

[npm1]

Oh, I realize we are yet to merge the PR for the error API to the spec :( see #498. So we do allow surfacing an error from the ID assertion endpoint. However, I don't think we allow IdentityProvider.resolve() to use this kind of error, so cannot surface it from continuation API.

[panva]

Oh, I realize we are yet to merge the PR for the error API to the spec :( see #498. So we do allow surfacing an error from the ID assertion endpoint. However, I don't think we allow IdentityProvider.resolve() to use this kind of error, so cannot surface it from continuation API.

Since the same kind of errors may be the result of the assertion endpoint being called directly as well as its subsequent interactions I'd say both should allow the same error shape to be returned.

[npm1]

Note that the continuation API is still under development. This seems reasonable to me. @cbiesinger feature request :)

[cbiesinger]

Yes adding something like IdentityProvider.reject would make a lot of sense

[samuelgoto]

Yes adding something like IdentityProvider.reject would make a lot of sense

+1.