是的，我认为至少在这个功能集的第一版中，明确指定会更好。我还没有遇到过必须自动创建群组的用例，也就是说，管理员完全可以在处理任何声明之前手动设置和配置群组。
也许在完成明确版本后，我们可以将自动创建作为一个选项引入？
就“群组设置”而言，可以这样设计：
设置部分：成员资格（即现有部分）
设置组标题：身份验证管理
设置：
- 服务：身份验证服务列表。“全部”将作为一个选项。此设置也将作为此功能集的“启用/禁用”状态。即默认值为“无”。
- 声明：用于标识 ID 令牌声明的文本输入。该功能的“描述”（或许可以在 meta 上的这篇帖子中）将解释支持的格式，例如布尔值、逗号分隔的字符串等。
- 模式：见下文
是的，如果存在“严格/宽松”设置，我们就必须对其进行简明扼要的解释。我认为处理这个问题的方法是聚焦于“添加”和“移除”。你可以这样描述：
设置：“模式”
选项 1（宽松）：
- 标签：“添加成员”
- 描述：“允许在身份验证时将成员添加到该群组”
选项 2（严格）：
- 标签：“添加和移除成员”
- 描述：“允许在身份验证时添加和移除成员。这将禁用手动成员控制。”
我之所以坚持保留“宽松”选项，是因为之前在与客户合作处理此类问题时，这是最常见的用例，即：
-
主要需求是根据外部服务中的状态允许访问某个群组
-
根据外部服务中的状态移除访问权限的需求相对次要，即人们确实会失去访问权限并应被移除，但这相对不那么重要
-
通常希望保留在 Discourse 中手动控制成员资格的能力。当我实施“严格”方法时，这曾让人感到“意外”（即“为什么 X 失去了成员资格？”），尽管已经进行了说明，且功能在技术上按预期运行。
是的，这很重要，因为人们经常会想知道“为什么”某人被添加或移除，特别是在严格模式下，而我们（即"Discourse"）无法控制外部身份验证服务所做出的声明的真实性。
或许可以新增一种“移除用户”和“添加用户”操作类型，其中包含负责该操作的身份验证服务，例如“移除用户（[服务名称]）”。