Clarify the role and usage of the `token` field

[ekovac]

There is currently some disagreement among implementers about whether the token field should be included in the Lightweight FedCM identity credential. For the purpose of this discussion I’m setting aside the question of naming, since "token" has an existing meaning in OAuth and that seemed to represent some of the discomfort when this issue was raised at the CG meeting. We can bike-shed the name of the field later; the main thing I want to resolve right now is how we expect the RP to make use of this.

In favor of including it, the token could be used in some IdP-specific way by the RP:

• The value could be posted to an embedded frame containing the IdP for distinguishing between multiple signed-in accounts (only useful if we assume that an implicit RSA grant exists.)
• The value could be used as a bearer token by the RP to issue a request to the IdP to retrieve more information about the user.
• It could be some sort of encoded value such as a JSON.stringify’d object containing additional information about the user that the IdP wants to provide to the RP, which may include one or both of the above two options.

In opposition to including it:

• In order to be useful, the token would need to be quite long-lived, which means using it as a bearer token would be risky, even if it was only effective for relatively low-risk operations like retrieving more detailed user profile information.
• Under the current design, the token would by necessity be RP-agnostic, which would introduce further risk from the previous point since it could only be revoked by the IdP in a blanket manner.

I don’t think we can punt on this issue; how we expect the RP to use this information has ramifications for how the user agent implementation of the account selection UI, expiration, etc should work, what other APIs need to be considered to make this feature useful at all, etc.

Some examples of questions that are inextricably tied to the inclusion or exclusion of the token parameter:

• How does the user agent handle expired UI hints when multiple accounts are present for a given IdP? If the user is presented with multiple indistinguishable accounts, this would be confusing, but only an actual problem if there’s an observable difference to the RP between accounts on a given IdP.
• Do we expect that IdentityProvider.getUserInfo() will hook into this to (indirectly, via the embedded IdP frame) provide RPs with access to the UI hint information for the account the user has selected?
• If neither the token field exists, nor does the getUserInfo API offer any value to RPs, is there any point in allowing multiple lightweight accounts per IdP here?

I would love to hear your thoughts on this, @bvandersloot-mozilla and @samuelgoto.

[bvandersloot-mozilla]

It could be some sort of encoded value such as a JSON.stringify’d object containing additional information about the user that the IdP wants to provide to the RP, which may include one or both of the above two options.

This is the most useful bit in my mind, however it may be able to be communicated out of band as we already assume that would be the case. This just allows some more dynamic control from the IDP rather than it being tied to whatever is shipped in the RP.

I agree that we should solve it soon though! Marked as agenda+f2f for TPAC.

[samuelgoto]

I would love to hear your thoughts on this, @bvandersloot-mozilla and @samuelgoto.

I think token is a red herring: I think this question is only occurring because you are navigator.credentials.store() something that isn't an IdentityCredential (which does indeed have a token) but rather an IdentityProviderAccount (which doesn't).

That is, I think that if you replaced navigator.credentials.store() with navigator.login.setStatus(), you'd be able to more clearly see "the job to be done" by what you are calling token here.

For example:

navigator.login.setStatus("logged-in", {
  accounts: [{
    name: "Sam Goto",
    photo: "https://accounts.idp.com/photos/1234.jpg",
    email: "goto@chromium.org"
  }]
});

[bvandersloot-mozilla]

That's a good point, Sam!

But then when you call navigator.credentials.get() what is the IdentityCredential like that you get back? Absent a token?

[bvandersloot-mozilla]

From the meeting, we will remove the token field and have it be absent on IdentityCredentials from Lightweight FedCM.

[ekovac]

Should I go through, remove the references to the token from the explainer, and send a PR? Or will you take care of that @bvandersloot-mozilla ?

[bvandersloot-mozilla]

I was planning to, but would be happy to review a PR for it :) Let me know which you prefer