Context (allow customization in the title)

[npm1]

Currently, Chrome's FedCM prompt assumes that the user is inside a sign-in flow, so uses language to match that:

Sign-in to rp.example with idp.example

The prompt is awkward when used inside of other flows, such as signing-up or unlocking content (e.g. a scholarly article) based on federated identity (e.g. a university student). While a user agent can choose a title different from Chrome's, the RP has no way to provide some hint about what type of flow is being presented to the user, so the user agent cannot customize the title.

[npm1]

Non goals

It is a non goal to come up with something that is infinitely extensible / expressive. It is ok if we end up with a limited enumeration of contexts in which we expect the prompt to be used.

Use Cases

There are some known use cases that we heard in the past from developers:

• Signing-in with your federated identity
• Signing-up with your federated identity
• Unlocking content (e.g. a scholarly article) based on your federated identity (e.g. your student id)

Here are a few examples [1, 2] used by Facebook Login (“login with” or ”continue with”) and Google Sign-in (“sign-in with”, “sign-up with”, “continue with” and “use with”).

Mocks

The API doesn’t make any visual UI structural changes other than the strings that we use. Currently, we have:

Use Case	String
Status Quo	Sign in to $RP with $IDP

And the proposal is to introduce 3 context modes (in addition to the default, "signin"):

Use Case	String
Sign-in	Sign in to $RP with $IDP (default)
Sign-up	Sign up to $RP with $IDP
Continue	Continue to $RP with $IDP
Use	Use $RP with $IDP.

Examples

const {token} = await navigator.credentials.get({
  identity: {
    // “signin” is the default, “signup”, “use” and “continue” can also be used
    context: "signup", 
    providers: [{
          configURL: "https://idp.example/fedcm.json",
          clientId: "1234",
    }],
  }
});

IDL

The specific way in which we propose to extend the FedCM API is the following:

Extensions to FederatedCredential
partial dictionary IdentityCredentialRequestOptions {
  // ...

  // A querying language that allows an RP to ask what it wants from the issuers.
  IdentityCredentialRequestOptionsContext context;
};

enum IdentityCredentialRequestOptionsContext {
  “signin”, “signup”, “use”, “continue”
};

Privacy Considerations

There are no privacy concerns introduced with this feature.

Security Considerations

The RP being given the opportunity to modify user agent UI needs to be treated carefully. To mitigate the risk, the API provides an enum of possible values that the RP can pass along to the user agent. In addition, the API does not dictate how exactly the user agent needs to include those values in their UI, which gives the user agent flexibility to use the context as it sees fit. For instance, if the user agent detects an RP that is incorrectly declaring context in some way, it may disable the FedCM API on that RP altogether, or it may simply ignore the RP context provided.

Open Questions

1. Is this something we should propose on a higher level, for the credential management API in general?
2. How does this integrate with the Multi-IdP API? How do we decide which context to use if they conflict with each other?

[Bojhan]

This would be in line with Seamless Access practices, we've done extensive testing as we are in the field that one can be granted access to the paper but not actually signed into the local site.

We currently use the word "Access" as in "Access through $name of institute". As FedCM does not persee imply that one is signing into a service, we would like to be able to continue using this nomenclature.

[npm1]

For requests for new context types, let's use a separate issue. Closing this one as the PR has landed with the initial context values.

[samuelgoto]

"Access through $name of institute".

Sounds reasonable to me.

For requests for new context types, let's use a separate issue. Closing this one as the PR has landed with the initial context values.

@Bojhan can you kick off a new github issue and describe a bit more the use case and uses? This seems like a reasonable addition, but we could use a bit more context.