You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think there is a follow up to #40 and #50, and I think is the best alternative direction to take on the balance.
The idea is to only put an IDP chooser in front of the user when there are no accounts matching the current IDP-RP in the connected accounts set. This gives us a lot more freedom in shaping the API's behavior because we no longer need to maintain secrecy of the RP to the IDP. This also facilitates happy-path login, without pushing contextual integrity concerns associated with sign up. I think this represents a fair compromise that prioritizes the users' interest, but is probably gated on FedCM making the same changes, and leaves a lot of freedom for UI innovation.
Here are the particular points of flexibility this gives us in API design:
The credential request can include the RP's information (e.g. client ID, origin) so the IDP can server-side control what accounts should appear where and in what order. This...
removes the need for browser-logic to filter by hints, instead allowing us to be a dumb pipe for the IDP-RP.
removes the need for a well-known resource, unless we retain it for IDP-picker opt-in where it would not need to be site-level
roll the metadata endpoint into the credential endpoint, since we no longer need to have a distinct RP-linked request before we request a credential
I think there is a follow up to #40 and #50, and I think is the best alternative direction to take on the balance.
The idea is to only put an IDP chooser in front of the user when there are no accounts matching the current IDP-RP in the connected accounts set. This gives us a lot more freedom in shaping the API's behavior because we no longer need to maintain secrecy of the RP to the IDP. This also facilitates happy-path login, without pushing contextual integrity concerns associated with sign up. I think this represents a fair compromise that prioritizes the users' interest, but is probably gated on FedCM making the same changes, and leaves a lot of freedom for UI innovation.
Here are the particular points of flexibility this gives us in API design:
The credential request can include the RP's information (e.g. client ID, origin) so the IDP can server-side control what accounts should appear where and in what order. This...
The text was updated successfully, but these errors were encountered: