On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:
Thanks for the suggestion, Yoav! It seems something fetch experts have
some concerns about, so we do not plan to proceed with that suggestion
at the moment.
I'd like to append a small addition to this I2S (mainly to avoid
having an additional PSA since it is very related to this one): we
would also like approval to only send Same-Site=None cookies in the
accounts endpoint, instead of all cookies (so not Same-Site=Lax or
Same-Site=Strict). This is also a breaking change but we do not
anticipate IDPs to break, and also plan to work with them to ensure
that they are aware of this change and are not caught by surprise.
To my non-FedCM expert brain, this doesn't feel like a small addition
(happy to be wrong!), beyond not understanding the scale of the risk,
the normal process questions come to mind i.e., is it specced, do we
have tests, what do other vendors think about it?
On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:
<owner hat off>
I left a comment
<https://github.com/fedidcg/FedCM/issues/428#issuecomment-1980469172> around
potentially adding a CORS mode that would help IDP servers
statically protect themselves from destination-change attacks. I
don't *think* it's a blocker, but it's worth considering something
along those lines to increase the solution's robustness to
configuration errors, and ensure it fails closed. (and ask IDPs'
security teams about their thoughts)
On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña <n...@chromium.org> wrote:
No, Sec-Fetch-Dest
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest>
is not changing. Sec-Fetch-Mode
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode>
is.
On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris
Harrelson wrote:
On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña
<n...@chromium.org> wrote:
On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav
Weiss wrote:
On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss
(@Shopify) <yoav...@chromium.org> wrote:
On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor
<mike...@chromium.org> wrote:
LGTM1
On 3/4/24 1:33 PM, Nicolás Peña wrote:
Contact emails
n...@chromium.org
Explainer
https://github.com/fedidcg/FedCM/issues/428
<https://github.com/fedidcg/FedCM/issues/428>
A few lines summarizing this issue would be
most useful when evaluating this and
understanding what y'all want to ship.
In particular, it'd be useful to understand
the request flow, what is the request's origin
(as IIUC, we're talking about requests issued
from the browser), and what is the request
destination that we may want IDPs to check.
Examples of the checks IDPs would have to make
would also be helpful.
Sure! From the spec
<https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint>,
here is a sample request:
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true
With this change, Sec-Fetch-Mode will now be cors in
this request and the IDP is expected to return the
following in the response (no preflight is performed):
Do you mean Sec-Fetch-Dest?
Access-Control-Allow-Origin: https://rp.example/
Access-Control-Allow-Credentials: true
Also, is the "identity assertion" endpoint the
same as the token endpoint
<https://github.com/fedidcg/FedCM/blob/main/explainer.md#token_endpoint>?
Yea. I think that explainer doc is not super up to date.
Specification
https://github.com/fedidcg/FedCM/pull/547
<https://github.com/fedidcg/FedCM/pull/547>
Summary
The fetches in the FedCM API are hard to
reason about because of the properties
required of them. While there is ongoing
discussion regarding the accounts
endpoint, there is broad consensus that
the ID assertion endpoint should use
CORS. This aligns security properties of
this fetch more closely to other fetches
in the web platform.
Blink component
Blink>Identity>FedCM
<https://g-issues.chromium.org/issues?q=status:open%20componentid:1456331&pli=1&authuser=0>
TAG review
Not requesting a TAG review. We have
already had extensive discussions with
Fetch experts.
TAG review status
N/A
Risks
Interoperability and Compatibility
This is a backwards incompatible feature,
but one that is warranted due to
consensus reached by our security
reviewers as well as other browser vendor
engineers. We have a manageable list of
IDPs that we know are using the FedCM API
and we have reached out to all IDPs that
are currently deploying FedCM to make
sure that they won’t break with this change.
Gecko: Positive based on TPAC discussions
and
https://github.com/fedidcg/FedCM/issues/428
<https://github.com/fedidcg/FedCM/issues/428>.
Not filing a standards position request
for small additions at the explicit
request from Firefox (they prefer PRs).
WebKit: Positive based on TPAC
discussions and
https://github.com/fedidcg/FedCM/issues/428
<https://github.com/fedidcg/FedCM/issues/428>.
Recently, standards position requests for
smaller FedCM features have been closed,
pointing to the (unresolved) main FedCM
one in
https://github.com/WebKit/standards-positions/issues/309
<https://github.com/WebKit/standards-positions/issues/309>so
not filing one for this.
Web developers: No signals
Other signals:
Ergonomics
N/A
Activation
N/A
Security
By adding CORS, we add a check that the
IDP explicitly agrees for the browser to
share the ID assertion response to the
RP. In addition, having this fetch align
with most other credentialed fetches in
the browser means that any future
protections are received by default, and
we do not have to special case this fetch.
WebView application risks
Does this intent deprecate or change
behavior of existing APIs, such that it
has potentially high risk for Android
WebView-based applications?
None
Debuggability
We surface errors when there is a network
problem with the ID assertion fetch. This
will help developers understand when this
feature introduces a problem in their
FedCM calls.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?
No. FedCM is not supported on Android
WebView.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
https://wpt.fyi/results/credential-management/fedcm-identity-assertion-nocors.https.html?label=experimental&label=master&aligned
<https://wpt.fyi/results/credential-management/fedcm-identity-assertion-nocors.https.html?label=experimental&label=master&aligned>(will
pass on Chrome once we ship)
Flag name on chrome://flags
None
Finch feature name
FedCmIdAssertionCORS
Requires code in //chrome?
True (because FedCM API does)
Tracking bug
https://issues.chromium.org/issues/40284123
<https://issues.chromium.org/issues/40284123>
Estimated milestones
DevTrial on desktop
120
DevTrial on Android
120
We want to ship on M124
Anticipated spec changes
Open questions about a feature may be a
source of future web compat or interop
issues. Please list open issues (e.g.
links to known github issues in the
project for the feature specification)
whose resolution may introduce web
compat/interop risk (e.g., changing to
naming or structure of the API in a
non-backward-compatible way).
https://github.com/whatwg/fetch/issues/1637
<https://github.com/whatwg/fetch/issues/1637>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5094763339710464
<https://chromestatus.com/feature/5094763339710464>
This intent message was generated by
Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are
subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e48f684%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e48f684%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed
to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0e70684-ee33-4e44-9ec3-6fcf3f0e96d3%40chromium.org.
