I'd like to remove my condition around my LGTM - I was able to reach out
to Ben offline to confirm that he's roughly in favor of the proposed
additions. Given that, I don't think we should block on reviews
(acknowledging a private chat is not an official position or statement
of support).
So, LGTM1 to ship.
On 10/27/23 5:27 PM, Chris Harrelson wrote:
However, even for WHATWG specs we have in the past blocked approval
until spec PRs landed in cases where the only blocker was editorial
review. This appears to be a similar situation.
On Fri, Oct 27, 2023 at 2:17 PM Rick Byers <rby...@chromium.org> wrote:
FedCM has decided to follow a WHATWG-like working mode
<https://github.com/fedidcg/FedCM/issues/431> where normative PRs
land only with 2+ implementer support. Given that reviews were
requested almost 2 months ago, and the blink launch process is
designed not to stall indefinitely on consensus, I don't think API
owners should be blocking this intent further on the PRs landing.
Mike, WDYT?
Rick
On Fri, Oct 27, 2023 at 4:45 PM Mike Taylor
<miketa...@chromium.org> wrote:
Thanks Nicolás and Yi.
LGTM1 % the PRs landing before this ships, and assuming
Mozilla does not have feedback that materially changes the API
shape. If that's the case, can you report back?
thanks,
Mike
On 10/26/23 10:27 AM, Nicolás Peña wrote:
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
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.
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.
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>.
--
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/0efea540-3115-4435-8837-fd4983ffd68d%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0efea540-3115-4435-8837-fd4983ffd68d%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/CAFUtAY9xmqXCW%3DHowGt_2FCjaoEp0SPzOuqhSD%3Dcg6wrjH2fhw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9xmqXCW%3DHowGt_2FCjaoEp0SPzOuqhSD%3Dcg6wrjH2fhw%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.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e830aa5-d892-4972-9bf6-910442aeb93e%40chromium.org.
