LGTM2 actually..
On Mon, Mar 18, 2024 at 7:40 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
LGTM1 to ship the ID assertion endpoint CORS requirements.
On Wed, Mar 13, 2024 at 3:11 PM Nicolás Peña <n...@chromium.org> wrote:
On Wednesday, March 13, 2024 at 7:37:29 AM UTC-4 Yoav Weiss wrote:
On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás
Peña wrote:
Regarding risk: we are going to implement this and
test the IDPs we know are currently using FedCM, but
we do not anticipate them to break since they are
currently already relying on using third-party cookies
in iframes. We also plan to have developer
outreach/blogpost for this change so developers
currently testing out FedCM are not caught by surprise.
Regarding vendor alignment: we have been working with
Firefox and Apple to align on the correct behavior of
the FedCM fetches: see
https://github.com/fedidcg/FedCM/issues/320
<https://github.com/fedidcg/FedCM/issues/320> and
https://github.com/fedidcg/FedCM/issues/428
<https://github.com/fedidcg/FedCM/issues/428>. This
I2S is a result of a lot of discussions, and the small
addition was a result of a very recent discussion
occurring on our FedCM CORS breakout session
<https://www.w3.org/2024/03/breakouts-day-2024/#b-15220813-651d-4795-98ae-a17434c1e50f>.
Regarding spec, during our breakout Anne also
mentioned that the small addition is not possible to
specify properly, as it depends on the ongoing cookie
layering work. I will add a note
<https://github.com/fedidcg/FedCM/pull/550> on the
spec in that fetch so IDPs know which cookies should
be sent.
Anyways, I understand it is a bit late to add
something to this I2S so if you prefer that we send a
separate I2S/PSA for the SameSite change, we can do
that instead.
Is the accounts endpoint the same endpoint to which this
intent applies? Or is it different from the ID assertion
endpoint?
If it's different, a separate I2S would be best. If it's
the same, then I think we can probably fold it into this
intent.
This change is to the ID assertion endpoint, which is
different from the accounts endpoint. Then based on your
comment, we will keep those two in separate intents. Consider
the small addition I suggested above removed.
On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike
Taylor wrote:
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.
Thanks for considering! Anne makes a good point that
active defense here (by filtering requests based on
destination) would work better against timing attacks than
passive defense (where the responses are blocked by the
browser). Please make sure that IDPs are aware of the
destination filtering requirement, by having it emphasized
in developer facing documentation.
Yes, we will work with devrel to continue ensuring IDP best
practices are easily discoverable.
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/CAOmohS%2BpVCGJ-mtXpG1oT7VWPv9YhQqh%2BpPipFDhBwmoiTBLsQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BpVCGJ-mtXpG1oT7VWPv9YhQqh%2BpPipFDhBwmoiTBLsQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
