-
Moderator: Heather Flanagan
-
Scribe: Kris, Heather
Call-in details: see https://www.w3.org/events/meetings/
Charter: https://github.com/w3c/fedidcg
-
Administrivia
-
Scribe volunteer(s)? Kris, Heather
-
Reminders:
-
-
FedCM
-
AOB
Heather: Reminder about the rules & regs for the W3C meetings. We’re starting by looking at the charter. At the TPAC meeting, we reviewed and came away with some feedback. Heather’s created a pull request about it, and we have a few comments on it so far (thanks Sam and John W.!). Does anyone have any feedback on it? Hearing nothing here, Heather will incorporate the comments into the PR.
Heather: Now onto FedCM. We have 2 issues to talk about. The first is 348.
Achim: Here’s the context. This has been an ongoing discussion for the last 2 years or so. The gist of it is that, assuming we’ll have web identity style APIs in the browsers, those could quite significantly change how IDPs interact with the users. This can also change how RPs interact with users as well - and many RPs might not be ready for this. So we need to give the RPs the ability to work with us on this user experience and usability. This issue is a write up explaining from an RP perspective about the expectations for the flow.
Achim: One simple example is the flow expected from a news publisher (shown in the issue). Achim reviewed the user flow to review the options.
George: I love the idea of approaching this from an RP perspective. I think there are probably more categories in the last category you touched on. I was thinking that I, as a user, want to be able to say whether or not an RP should use an IdP just because I’m already signed in to an IdP. I want to think about this more, but I think our current mechanisms might give all of the options users would want to be able to use.
Achim: Yes, this isn’t to change the user choices, but to focus on the RP options.
Peter KH (from chat): I don't think that trust tokens will give you that information
George (from chat): I was thinking that if the RP wrote a trust token into the browser then the RP could check to see if the browser has a trust token when the browser shows up.
Ben: I think some of this already has some hooks in the broader credential management API. Something I think will be harder is does an IdP handle specific scopes.
Sam: I have a clarification question: (thank you for this!) what was your intent with the purple boxes? Are you thinking about the user experience or is this information that the RP needs?
Achim: It’s a bit tricky. The boxes are - assuming we have some sort of synchronization between the RP and IdP - the purple boxes are what the RP would need information-wise for decision points. The purple boxes relate to business choices that the RP needs to make. It’s not a technical flow, but what information is needed to make the business choices.
George: One thing that would help would be what of these RP requirements are not supported by today’s identity protocols?
Achim: This is largely focused on how to support the flow without the user leaving the RP site. This maps to a couple of current openid connect parameters.
Brian D (from chat): Not shown, but would be nice to show -- conditional user choice of starting this flow at all, after the user visits the site. For a concrete example users may globally disable sign-in with Google either in their account or browser (with fedcm) and bail out prior to the purple decision points.
Achim (from chat): Good Point Brian, I think there are already these sort of generic user settings in the current chrome FedCM implementation
Heather: So the next item on our list touches on multiple IdPs (issue #319). Sam would you like to review?
Sam: Yes, but Christian or Nicholas are likely better for the overview.
Christian: The proposal is that we combine the multiple get calls into a single call, The idea is that we have a microtask before the get calls, and the microtask handles the combination.
Sam: This is something we shared at TPAC, but we didn’t get into the details. (Sam presented illustrative mocks showing what it is they’re trying to do with this issue.) The constraint in the current proposal is that it only supported a single IdP being used. The feedback from Mozilla that we got - and think is valuable - is that multiple IdPs should be supported.
Tim: How do you decide who shows up in the button?
Sam: The position we’re going with is that it’s an RP choice.
Christian: Everything is up to the RP, but the hope is we won’t end up with multiple buttons (like the NASCAR screen).
Sam: The browser wants to be opinionated with the choice of the IdP. (We identified a mock bug that Sam will look at.)
Brian: RPs often select IdPs to highlight a particular IdP based on a particular user journey. I want to highlight that RPs use knowledge of the user and their journey to help this flow.
Ben: I just wanted to say there’s currently a bit of a double NASCAR issue with the mock. If a user makes initial selections, a new NASCAR choice can be presented - and so the question is do we want to support that?
Heather: With my chair hat off, this is a particular problem in academia. For academic RPs, there can be quite a large number of IdPs options that should reasonably be presented to the user. Advocating that we think about other scenarios than B2C.
Achim: I think the prioritization of the IdP selection is very important to avoid the winner-take-all scenario.
George: We need to be very careful about how we present information to users. I agree that the RP needs to have control about when the options come up, but we may need to educate the user about the choices involved as well. We may be leading the user down a path of choosing something again, and we need to be careful with that.
Ben: There is a potential privacy leak with the mock on the right with the multiple IdPs since you would need to expose information before the user has picked a given IdPs.
Christian: I Just wanted to say that none of these mocks are final for what Chrome is planning to ship.
Sam: +1 to what Christian said - and want to add that we expect this to take a while to figure out. This is more about are we going in the right direction.
Christian: what should we do about CORS in our API? Currently spec has a header that allows the IdP to tell whether a request came from the FedCM UI rather than an HTML HTTP request. The fetch spec already has a similar header that could solve a similar purpose. One proposal is to add an identity value to that fetch spec; that seems to have some support. The more controversial/complex question si whether we should use CORS for the request to be sent. Right now, the requests are made in no-CORS mode. We cannot use regular CORS becaus that would send th origin of the RP in the request. Many endpoints should not know who the RP is for privacy reasons. There is a proposal to send the manifest request to the null origin as a way to have them opt in to FedCM. The issue in general to CORS is that if you require it, that implies that regular website can access them too if you have a data URL. Having a null origin is not a protection for having regular websites making a request. If you think of this as an opt-in to FedCM, perhaps a better option is to have the .well-known file which should explicitly list the provider manifest. If you have that file that’s a strong opt-in. CORS with a null origin does not offer specific protection or security advantage. Suggest we continue in no-CORS mode. More details in the comment.
Ben: Agree that a sec fetch dest makes more sense than a custom sec header. Mozilla is happy to do that as well. Removal of CORS entirely raises two particular issue: 1) the id_token request should be CORS.
Christian: Probably ok to do that, but Chrome stil has 3pc, so if you require CORS, then websites could get an id_token using fetch without user interaction.
Ben: the server would have to check the sec fetch dest header.
Christian: how bad is the failure mode if they don’t check that header? Can see the argument for data explicitly exposed to the RP using CORS.
Achim: an API call from JS side would definitely be with CORS.
Nicolas (from chat): Essentially the endpoints are not meant to be used directly by RPs so CORS is not appropriate.
Nicolas: Trying to make a point for non-use of CORS. When the IdP is comfortable with the other party directly fetching and reading a resource is not the case for the id_token endpoint. In that case, the IdP is telling FedCM they are comfortable once the user has granted permission. Adding CORS is over-granting permissions from the IdP to the RP. The RP should not be able to perform a fetch from that endpoint and read the content regardless of what it actually receives.
Ben: if you have the sec fetch dest header, you’re not enabling that.
Nicolas: CORS only introduces a problem if the IdP does not check sec fetch dest.
Ben: yes, that’s a failure mode. Not checking that header is a huge failure.
Christian: You can argue that if the IdP already check that header, there’s no need to use CORS
Ben: maybe
Christian: it doesn’t provide actual security.
Ben: it is nice to have an origin header instead of a referrer header.
Achim: we discussed the referrer a while ago. If they have client-side they will use CORS, if they have a redirect flow they’ll check the headers.
Sam: agree with the intuition that this falls in a CORS typical use case, but as looking at it, we aren’t sure what benefit it adds while also believing it introduces a harm. If it’s unnecessary from a least privilege perspective, how could that overweigh the potential harm?
Achim: the referrer is definitely a must from the IdP server side.
Christian: definitely sending the referrer in these requests. If this is only about which header to send, we can also send the origin header. The question is should we require the origin in the response.
Ben: need more time to think about this.
Sam: we want to show we have thought about this deeply, and we’re coming to the conclusion this might actually be harmful. For the uncredentialed case, the harmful case may be smaller, but the benefits are also likely smaller, so we’re converging on not using CORS there either.
Yi (from chat): it also puts extra burden to IdPs to carefully config endpoints differently. worth paying the cost if it adds extra value but we don't find anything convincing.
Brian: bringing in a different perspective: from the IdP, being able to host a single set of endpoints to service both browsers and non-browsers and support backward compatibility. ideal scenario is to have one set of endpoints. Arguing that if we can maintain that, that would be an ideal case.
Ben: The destination of the request is actually the browser and not the RP, which makes a lot of sense. Especially because in Mozilla’s model, all these requests are occurring in a browser process not a content process. If FedCM is the thing managing the exchange of info between the process and the content based on user consent, and sec fetch dest is set properly, this might make sense. Have you spoken with the other two commenters?
Sam: yes, have agreement from one taht CORS isn’t necessary, but still trying to reach out to the other. Also wrote in the spec our expectations wrt fetch.
Ben: will need to look at that patch. Wrote all our code in terms of the fetch API, so can provide some sanity checks there. Will take an action item to comment back on GitHub.
-
Heather Flanagan (Spherical Cow Consulting)
-
Kris Chapman (Salesforce)
-
Achim Schlosser (European netID Foundation)
-
Chris Lemmons (Comcast)
-
Dani Katzman (Cross River)
-
Nicolas Pena Moreno (Google)
-
Benjamin VanderSloot (Mozilla)
-
Tim Cappalli (Microsoft Identity)
-
Sam Goto (Google)
-
Michael Knowles (Google)
-
George Fletcher (Capital One)
-
Zachary Tan (Google)
-
Kaan Icer (Google)
-
Christian Biesinger (Google)
-
Peter Kotwicz (Google)
-
Brian Daugherty (Google)
-
Yi Gu (Google)