For the record, we did request reviews: here
<https://github.com/fedidcg/FedCM/pull/498#issuecomment-1703004458>
and here
<https://github.com/fedidcg/FedCM/pull/500#issuecomment-1706732499>.
I'll ask to see if they can be added to the set of users from whom we
can 'request review' in GitHub UI.
On Wednesday, October 25, 2023 at 7:17:53 PM UTC-4 Yi Gu wrote:
We sync’d with @bvandersloot-mozilla
<https://github.com/bvandersloot-mozilla> in FedIdCG [1] and they
have confirmed that it’s on their list.
[1]
https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes
<https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes>
On Wed, Oct 25, 2023 at 6:51 PM Mike Taylor
<miketa...@chromium.org> wrote:
On 10/25/23 4:14 PM, Yi Gu wrote:
Thanks Yoav for the review!
> It'd be useful to write a short (inline?) explainer here
outlining what this does and how it'd look like.
Specifically, would we start throwing on errors in scenarios
that silently failed before?
For the Error API, it allows IdP to signal to the browser
about the sign-in failure details such that the browser can
make sure the user is kept informed with possibly next steps.
Without this API, when a user clicks the "Continue as Name"
button to sign-in, if it fails for whatever reasons, the
browser rejects the promise silently so the user could be
confused about the status. The fact that we are delaying
rejecting the promise (for privacy reasons) would make it
worse because the website wouldn't learn about the failure
immediately either. With this API, the browser will first
show a native UI with proper strings to explain the error to
users and possibly allow users to learn more about next
steps. It will also reject the promise with the errors (if
provided by IdP) via IdentityCredentialError instead of a
generic DOMException (which we currently use). You could find
more details here
<https://github.com/fedidcg/FedCM/issues/488#issuecomment-1679742999>.
For the AutoSelected Flag API, it shares whether auto
re-authentication has been triggered during the flow with
both IdP and RP. By default the CredentialManagement API
supports credential auto selection when possible. However,
the browser may decide not to trigger auto selection for
legitimate reasons. While the exact reason should be opaque
to IdP or RP, we could share with them the outcome such that
they can better understand the flow and handle things
differently. e.g. for metrics purposes they could know how
many transactions were done with auto re-authentication to
better understand the performance; in addition, an IdP can
use the signal (boolean) to support some security related
features. e.g. a user may prefer explicitly selecting an
account with an IdP, if the IdP gets a token request that
shows the account was automatically selected, they could
reject the request and trigger a new sign-in flow to ask for
explicit user mediation. You could find more details here.
<https://github.com/fedidcg/FedCM/issues/497#issuecomment-1698174046>
> What's preventing these PRs from landing?
We aligned with Mozilla, who is prototyping FedCM in Firefox
right now, that such spec changes should be reviewed by at
least two implementers before merging. While we have
discussed the two APIs
<https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md>
at FedIdCG and it "generally looks reasonable", it's not yet
formally reviewed by Mozilla (hence the "Under consideration"
signal).
I don't see anyone from Mozilla as a reviewer for either PR -
is there a plan to request review from them?
Thanks.
Yi
On Wed, Oct 25, 2023 at 11:19 AM Yoav Weiss
<yoavwe...@chromium.org> wrote:
On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev
wrote:
Contact emails
y...@chromium.org
Explainer
https://github.com/fedidcg/FedCM/issues/488
<https://github.com/fedidcg/FedCM/issues/488>
It'd be useful to write a short (inline?) explainer here
outlining what this does and how it'd look like.
Specifically, would we start throwing on errors in
scenarios that silently failed before?
https://github.com/fedidcg/FedCM/issues/497
<https://github.com/fedidcg/FedCM/issues/497>
Similarly a short explainer outlining what this does and
how would help reviewing this intent.
Specification
https://github.com/fedidcg/FedCM/pull/498
<https://github.com/fedidcg/FedCM/pull/498>
https://github.com/fedidcg/FedCM/pull/500
<https://github.com/fedidcg/FedCM/pull/500>
What's preventing these PRs from landing?
Design docs
https://docs.google.com/document/d/1DEjbFSAMmmT47_n8JBLmcleCNPz_WS5a24WDrglSQMo/edit?usp=sharing
<https://docs.google.com/document/d/1DEjbFSAMmmT47_n8JBLmcleCNPz_WS5a24WDrglSQMo/edit?usp=sharing>
Summary
Dedicated APIs to help developers and users to better
understand the authentication flow. Both APIs are
triggered post user permission to sign in to an RP
with an IdP. i.e. after the user clicks the "Continue
as" button.
- With Error API, if a user's sign-in attempt fails,
the IdP can share the reasons with the browser to
keep both users and RP developers updated.
- With AutoSelectedFlag API, both IdP and RP
developers could have a better understanding about
the sign-in UX, evaluate performance and segment
metrics accordingly.
Blink component
Blink>Identity>FedCM
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM>
Search tags
fedcm <https://chromestatus.com/features#tags:fedcm>
TAG review
https://github.com/w3ctag/design-reviews/issues/893
<https://github.com/w3ctag/design-reviews/issues/893>
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
These are extensions to the FedCM API. Apple and
Mozilla have both expressed a positive opinion on the
initial FedCM API
<https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ>[1]
and Mozilla is currently prototyping
<https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ>the
FedCM API. If a user agent chooses to not implement
these extensions, it may hurt the quality of the UI
that they can provide to users, but should not break
the FedCM flow.
Gecko: Under consideration
(https://github.com/fedidcg/FedCM/pull/498
<https://github.com/fedidcg/FedCM/pull/498>
https://github.com/fedidcg/FedCM/pull/500
<https://github.com/fedidcg/FedCM/pull/500>) Firefox
has asked us not to file standard position, and they
provided feedback in the GitHub PR.
WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/249
<https://github.com/WebKit/standards-positions/issues/249>)
Web developers: Positive These features are being
developed to address existing use-cases which will
not be possible once third-party cookies are phased out.
Other signals:
Security
For the Error API, the browser may open a pop-up
window with a URL provided by the IdP when an error
happens. It has the same web platform properties as
what one would get with
window.open(url,””,”popup,noopener,noreferrer”)) that
loads the error.url. There's no communication between
the website and this pop-up is allowed (e.g. no
postMessage, no window.opener). We have also
considered the potential phishing risk and had the
mitigations in place (see the explainer for more
details).
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?
FedCM is not supported in WebView
Debuggability
The two new APIs are extensions of the FedCM API
which has proper devtools support.
For the Error API, the browser takes an error
returned by the IdP (if any) and rejects the promise
with an error exception. For RP developers, the only
thing that they need to take care of is handling the
exception which may not need DevTools support. For
IdP developers, the only potentially useful
information that we could add to the console is when
the error URL is cross-site to the IdP in which case
we won't use the error URL in the flow.
For AutoSelectedFlag API, it just introduces a new
boolean for both IdP and RP developers to parse. We
believe that in this case we don't need to provide
extra information in DevTools.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, Android,
and Android WebView)?
FedCM is available in all Blink platforms except for
WebView.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes.
Testing on wpt.fyi is blocked on
https://github.com/web-platform-tests/wpt/pull/40709
<https://github.com/web-platform-tests/wpt/pull/40709>
getting reviewed and merged. Otherwise, we are adding
tests that will be in the credential-management
directory as shown on the WPT dashboard here:
https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned
<https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned>
DevTrial instructions
https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md
<https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md>
Flag name on chrome://flags
chrome://flags/#fedcm-error
chrome://flags/#fedcm-auto-selected-flag
Finch feature name
FedCmError
FedCmAutoSelectedFlag
Requires code in //chrome?
True
Tracking bug
https://crbug.com/1477253 <https://crbug.com/1477253>
Launch bug
https://launch.corp.google.com/launch/4273845
<https://launch.corp.google.com/launch/4273845>
Sample links
https://drive.google.com/file/d/1Z8r4OkQMmKulGv-vf-XTfwqh6VUyGZF9/view?usp=sharing
<https://drive.google.com/file/d/1Z8r4OkQMmKulGv-vf-XTfwqh6VUyGZF9/view?usp=sharing>
Estimated milestones
Shipping on desktop
120
Shipping on Android
120
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5384360374566912
<https://chromestatus.com/feature/5384360374566912>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/YfaGM8v-Ocs/m/4E0RHMhJAwAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/YfaGM8v-Ocs/m/4E0RHMhJAwAJ>
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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCM8FnGsYjCQhzskrzU4RK9fMvpSBv23VV4Cdtr%2BMj0O2w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCM8FnGsYjCQhzskrzU4RK9fMvpSBv23VV4Cdtr%2BMj0O2w%40mail.gmail.com?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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3bf599d-4ce2-482d-8153-87bba1dd1836%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3bf599d-4ce2-482d-8153-87bba1dd1836%40chromium.org?utm_medium=email&utm_source=footer>.
