Specify the mode API

[tttzach]

Fixes w3c-fedid/active-mode#2

---

Preview | Diff

[cbiesinger]

Generally looks good. See comments below. We should probably add a Note: in some appropriate place that the user agent should consider displaying the account chooser in a louder way if mode is active.

[TallTed]

Minor, human-facing

[TallTed]

trivial, editorial

[cbiesinger]

Thanks, looks good modulo two minor comments

[wseltzer]

Discussed in Oct. 15 call. [minutes to be linked]
https://github.com/fedidcg/meetings/blob/main/2024/2024-10-15-notes.md

[tttzach]

@aaronpk @bvandersloot-mozilla @philsmart Please take a look!

[philsmart]

From the perspective of at least the R&E federations I am involved with, 'active' mode is a better fit. This mode supports authentication with Identity Providers (IdPs) that the user has not yet logged into (as signalled by the login status API).

Supporting multiple IdPs in 'active' mode would be helpful, but it could result in the same account fetching issues as enabling multi-IdP in 'passive' mode. The 'passive' mode addressed this (if I recall correctly) by including only the IdPs you've signed into, which brings us back to the same issue (unable to use an IdP you've not logged into). This can be addressed for now by using an external IdP discovery service and populating FedCM with a single IdP in 'active' mode.

For what it's worth, I agree with renaming 'button' and 'widget' to 'active' and 'passive', it is clearer.

[npm1]

This part about pending request is also not precise enough. Presumably this is also scoped to something (perhaps top-level browsing context?). In addition, you are never going to reach this because we disallow this from credential management in 8.2 https://w3c.github.io/webappsec-credential-management/#algorithm-request so that will need to be modified as well at some point

[tttzach]

Good catch on the scoping... let me know if |W|'s top-level browsing context works or if that should be even more specific. Should modifying 8.2 be in this PR?

[npm1]

No, you cannot modify 8.2 in this PR since that is a separate repo. I also filed an issue because that uses the wrong scope as well. Need to think how to fix it while also allowing the active mode to be prioritized (eg supersede a pending passive mode request)

[npm1]

Hmm but isnt the abort signal only for the developer to use? This does not make sense to me, is this actually what we do?

[tttzach]

No we don't actually use the abort signal for this case, but instead we directly reject the previous request. Though this was why its worded this way: #660 (comment)

Maybe we can get rid of as if a {{CredentialRequestOptions/signal}} of [=AbortSignal/aborted=] was given to it.?

[bvandersloot-mozilla]

why SHOULD?

[hlflanagan]

PR further discussed in https://github.com/w3c-fedid/meetings/blob/main/2024/2024-10-22-notes.md
(@bvandersloot-mozilla will review; the issue raised (w3c-fedid/active-mode#6) will be added to the text as a related problem that still needs to be solved)

[tttzach]

Thanks for the review, please take another look!

[tttzach]

No we don't actually use the abort signal for this case, but instead we directly reject the previous request. Though this was why its worded this way: #660 (comment)

Maybe we can get rid of as if a {{CredentialRequestOptions/signal}} of [=AbortSignal/aborted=] was given to it.?

[tttzach]

Good catch on the scoping... let me know if |W|'s top-level browsing context works or if that should be even more specific. Should modifying 8.2 be in this PR?

[npm1]

Looks good!

[tttzach]

@bvandersloot-mozilla Friendly ping :)

[hlflanagan]

Note: discussed during https://github.com/fedidcg/meetings/blob/main/2024/2024-11-12-notes.md ; PR blocked pending @bvandersloot-mozilla review.