Specify account labels #669
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.
Why the discrepancy between labels and include?
There was a problem hiding this comment.
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.
A dictionary with a single string? What are we thinking this could be extended to?
There was a problem hiding this comment.
"exclude" is the obvious one. Conceivably we could also allow specifying multiple labels (could require all of them to match or just one)
|
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