Remove account information from returned IdentityCredential

[ekovac]

@samuelgoto has suggested that we should not provide the login-status-stored account information in the IdentityCredential. Effectively, the login-status-stored account information would only be for presentation via the browser-controlled account selection UI, a replacement/precaching mechanism for the accounts_endpoint fetch.

This would allow future extension where information on the IdentityCredential could be a verifiable identity assertion, such as in the proposed Delegation-Oriented FedCM.

Would like to hear @bvandersloot-mozilla 's thoughts on this.

[samuelgoto]

@samuelgoto has suggested that we should not provide the login-status-stored account information in the IdentityCredential. Effectively, the login-status-stored account information would only be for presentation via the browser-controlled account selection UI, a replacement/precaching mechanism for the accounts_endpoint fetch.

Yeah, correct. Specifically, in this example in the explainer:

  const {profile: {id, name, email, picture}} = await navigator.credentials.get({
  	identity: {providers: [{url: "https://example.com"}]}
  });

The RP is getting the user's name/email/picture.

I'm suggesting that we do not share that metadata to the RP from the navigator.login.setStatus() call, but rather, only share that information if the id_assertion_endpoint was used.

What I intended to say was that, IF it was useful for lightweight fedcm to allow the IdP to implement the id_assertoin_endpoint entirely on the client side, that we could provide that functionality via a call that is separate to the navigator.login.setStatus(), and I think a good candidate would be to go back to some of your early thoughts on navigator.credentials.create() from before.

So, my mental model is that navigator.login.setStatus is a JS client-side alternative for the HTTP server-side accounts_endpoint, and navigator.credentials.create is a JS client-side alternative for the HTTP server-side id_assertion_endpoint.

For example:

// On example.com
navigator.credentials.create({
  identity: {
     profile: {
       name: "Sam",
       email: "sam@goto.com"
     }     
  }
});

// On the RP
const {profile: {id, name, email, picture}} = await navigator.credentials.get({
  	identity: {providers: [{url: "https://example.com"}]}
  });

// now name = "Sam" and email = "sam@goto.com"

This would allow future extension where information on the IdentityCredential could be a verifiable identity assertion, such as in the proposed Delegation-Oriented FedCM.

Correct.

I think it is going to be useful to have a client-side JS alternative to the id_assertion_endpoint in some cases. It may not be useful for this case, so feel free to ignore. But just wanted to share an idea that I think will reconcile well with the delegation-oriented FedCM.

[johannhof]

Sam's suggestion makes sense to me.

[bvandersloot-mozilla]

I'm suggesting that we do not share that metadata to the RP from the navigator.login.setStatus() call, but rather, only share that information if the id_assertion_endpoint was used.

I don't follow why from your logic. If, as you said, "navigator.login.setStatus is a JS client-side alternative for the HTTP server-side accounts_endpoint", and the data is coming from the accounts_endpoint in the FedCM case, why would we not disclose the data from setStatus?

[samuelgoto]

and the data is coming from the accounts_endpoint in the FedCM case

The data that is shared to the RP in the IdentityCredential in the full-FedCM case isn't coming from the accounts_endpoint, it is coming from the id_assertion_endpoint.

[bvandersloot-mozilla]

The data that is shared to the RP in the IdentityCredential in the full-FedCM case isn't coming from the accounts_endpoint, it is coming from the id_assertion_endpoint.

Is there a PR # that has this? I can't find it and the Editor's Draft only has the token and continue_on coming from the id_assertion_endpoint

[samuelgoto]

the Editor's Draft only has the token and continue_on coming from the id_assertion_endpoint

The RP gets an IdentityCredential: there is nothing that is shared with the RP other than the token (which, as you said, comes from continue_on or the id_assertion_endpoint) and the boolean isAutoSelected (which the browser provides).

The accounts_endpoint is only used to construct an account chooser, but nothing else.

[bvandersloot-mozilla]

Ah, I misunderstood- I thought FedCM currently gave the account information on the returned the IdentityCredential via the CredentialUserData mixin. If it doesn't +1 from me to remove this as well.

[samuelgoto]

returned the IdentityCredential via the CredentialUserData mixin.

Ah, interesting! It never occurred to me that we could use the mixin! That's great to know actually! But yeah, we don't currently use it at the moment.

If it doesn't +1 from me to remove this as well.

I just wanted to note that, what I hope to suggest is that, in the absence of an id_assertion_endpoint, we don't share the token in the IdentityCredential, but IIUC, in lightweight mode, the id_assertion_endpoint is not required but is optional, so, when one is provided we should use it and return a token, but when one is not we should not override that option that the IdP has made and share the data we got from the navigator.login.setStatus().

In other words, setting navigator.login.setStatus() should not serve as a replacement to id_assertion_endpoint.

I think I'm not able to quite express my suggestion precisely, but I hope this is more or less making sense to you all :)