Specify the mode API #660
Specify the mode API #660
Conversation
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Discussed in Oct. 15 call. [minutes to be linked] |
|
@aaronpk @bvandersloot-mozilla @philsmart Please take a look! |
|
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. |
spec/index.bs
Outdated
| 1. Let |mode| be |options|'s {{IdentityCredentialRequestOptions/mode}}. | ||
| 1. If |mode| is [=active=] | ||
| 1. If [=transient activation=] is not present, return (failure, true). | ||
| 1. If [=transient activation=] is present and there is a pending |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
spec/index.bs
Outdated
| 1. If [=transient activation=] is present and there is a pending | ||
| request where |mode| is [=passive=], cancel the previous request | ||
| as if a {{CredentialRequestOptions/signal}} of | ||
| [=AbortSignal/aborted=] was given to it. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.?
|
PR further discussed in https://github.com/w3c-fedid/meetings/blob/main/2024/2024-10-22-notes.md |
spec/index.bs
Outdated
| 1. If [=transient activation=] is present and there is a pending | ||
| request where |mode| is [=passive=], cancel the previous request | ||
| as if a {{CredentialRequestOptions/signal}} of | ||
| [=AbortSignal/aborted=] was given to it. |
There was a problem hiding this comment.
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.?
spec/index.bs
Outdated
| 1. Let |mode| be |options|'s {{IdentityCredentialRequestOptions/mode}}. | ||
| 1. If |mode| is [=active=] | ||
| 1. If [=transient activation=] is not present, return (failure, true). | ||
| 1. If [=transient activation=] is present and there is a pending |
There was a problem hiding this comment.
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?
| 1. Let |result| be the result of running | ||
| [=fetch the config file and show an IDP login dialog=] with | ||
| |provider| and |globalObject|. | ||
| 1. If |result| is failure, return (failure, false). |
There was a problem hiding this comment.
Should this be true or false? true = no delay. False = delay the rejection. Or if it depends on the reason for failure then perhaps the algorithm in the previous step needs to return that
| 1. Let |result| be the result of running | ||
| [=fetch the config file and show an IDP login dialog=] | ||
| with |provider| and |globalObject|. | ||
| 1. If |result| is failure, return (failure, false). |
Fixes w3c-fedid/active-mode#2
Preview | Diff