-
Notifications
You must be signed in to change notification settings - Fork 74
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
Specify account labels #669
base: main
Are you sure you want to change the base?
Conversation
1. If |config|.{{IdentityProviderAPIConfig/accounts}}.{{IdentityProviderLabelConfig/include}} | ||
was specified: | ||
1. For every |account| in |accountList|, remove |account| from |accountList| if |account|'s | ||
{{IdentityProviderAccount/labels}} does not [=list/contain=] |
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.
Why the discrepancy between labels
and include
?
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 mean, this is what we settled on in the explainer. I don't recall why we made this choice specifically, though. @samuelgoto do you remember?
@@ -1053,13 +1059,18 @@ dictionary IdentityProviderBranding { | |||
USVString name; | |||
}; | |||
|
|||
dictionary IdentityProviderLabelConfig { |
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.
A dictionary with a single string? What are we thinking this could be extended 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.
"exclude" is the obvious one. Conceivably we could also allow specifying multiple labels (could require all of them to match or just one)
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.
lgtm modulo naming
Discussed on https://github.com/fedidcg/meetings/blob/main/2024/2024-11-26-notes.md. Needs further review. |
I would like to reiterate why we think this proposal is better than expanding login_hint/domain_hint to cover this. Conceptually, we envision this as an IDP-internal selector that the RP need not/should not be aware of. Hence the design of putting it in the config URL to filter accounts from the account endpoint, both of which are under control of the IDP. Putting this under control of the RP makes it easy to make programming errors -- forgetting to specify an account label leads to a UI with accounts that will not work, which is not a great user experience. Keeping this under control of the config file avoids that. I realize that I did not do a good job framing this well in the meeting, sorry about that. I hope this helps in addition to the "alternatives considered" in #553. |
Bug: #553
Preview | Diff