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
>>
>>
>> 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
>>
>>
>> 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/500
>>
>>
>> What's preventing these PRs from landing?
>>
>>
>>
>> Design docs
>>
>> 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
>>
>> 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/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)
>>
>> 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 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
>>
>>
>> DevTrial instructions
>>
>> 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
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4273845
>>
>> Sample links
>>
>> 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
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype: 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/CACh2XCNbNHshaR_OismwF0_aynN_Cv41TNK7ztpga%3DqHPEqQqA%40mail.gmail.com.

Reply via email to