-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move the credential chooser to after the popup/redirect #29
Move the credential chooser to after the popup/redirect #29
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I'm a bit unsure why Scenario 2 & 3 are necessary though. Maybe we don't need 3 key scenarios but rather one (which is probably a good thing? 😅 )
README.md
Outdated
}, | ||
] | ||
} | ||
}); | ||
``` | ||
The browser looks into the credential store and sees that there is a credential this is effective for `example.com` from `login.idp.net`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The browser looks into the credential store and sees that there is a credential this is effective for `example.com` from `login.idp.net`. | |
The browser looks into the credential store and sees that there is a credential that is effective for `example.com` from `login.idp.net`. |
README.md
Outdated
|
||
### Scenario 2: User intends to link to an identity provider they are already logged in to | ||
### Scenario 2: User logs in with one of many identity providers, or other types of credential |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure what Scenario 2 adds to the proposal. What is it that we want user agents to implement here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Collecting IdentityCredentials from the credential store.
- Flexibility to allow the UA to show multiple credential types in a credential chooser.
In this scenario the user has made some indication to the site that they want to log in. | ||
The specifics of that interaction dictate what Credential types are appropriate. For sake of discussion, let's say the credentials defined here and a PasswordCredential would be good. | ||
The page then calls the following: | ||
### Scenario 3: User intends to link to an identity provider they are already logged in to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with Scenario 3, what is the delta to FedCM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- For IDPs it is easier to work with, despite having the same UX.
Co-authored-by: Johann Hofmann <[email protected]>
7923a67
to
445f9dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Seems good to merge and iterate on further :)
loginTarget: "redirect", | ||
}, | ||
] | ||
} | ||
}); | ||
``` | ||
|
||
This example shows the use perfect for a "Log in with Foo" button (use case #1, and use case #2), where one identity provider is presented, and if the user has not already logged in, they may be redirected to that provider's login page. This redirect behavior is only permitted when there is only one provider in the list. A provider with `loginURL` field indicates that this is the expected mode. If `loginURL` is present, but `origin` is not, its value can be inferred as the origin of the link. | ||
This example shows the use perfect for a "Log in with Foo" button, where one identity provider is presented, and if the user has not already logged in, they may be redirected to that provider's login page. This redirect behavior is only permitted when there is only one provider in the list. A provider with `loginURL` field indicates that this is the expected mode. If `loginURL` is present, but `origin` is not, its value can be inferred as the origin of the link. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's "the use perfect"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it could be rewritten as "the use of the API that is perfect". "use" as in the noun meaning occasion or need. Agreed that this could be reworded
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example shows the use perfect for a "Log in with Foo" button, where one identity provider is presented, and if the user has not already logged in, they may be redirected to that provider's login page. This redirect behavior is only permitted when there is only one provider in the list. A provider with `loginURL` field indicates that this is the expected mode. If `loginURL` is present, but `origin` is not, its value can be inferred as the origin of the link. | |
This example shows a scenario that is perfect for a "Log in with Foo" button, where one identity provider is presented, and if the user has not already logged in, they may be redirected to that provider's login page. This redirect behavior is only permitted when there is only one provider in the list. A provider with `loginURL` field indicates that this is the expected mode. If `loginURL` is present, but `origin` is not, its value can be inferred as the origin of the link. |
Builds on top of #28 .
Resolves many of the concerns of #26.
Obviates #23 and #24.