OpenID Connect webfinger 端点是用户帐户到 OpenID Connect 提供商的映射吗？
Is the OpenID Connect webfinger endpoint a map of user account to OpenID Connect providers?
在 中，示例答案开头为：
Suppose Carol wishes to authenticate with a web site she visits using OpenID Connect. She would provide the web site with her OpenID Connect identifier, say carol@example.com. The visited web site would perform a WebFinger query looking for the OpenID Connect provider.
听起来 example.com 还不知道哪个 OpenID 连接提供商可以对 Carol 进行身份验证？它必须使用 Carol 的电子邮件地址作为查找键来找出哪些 OpenID Connect 提供商可以对她进行身份验证？
很多网站都有 Authenticate with Github 或 Authenticate with Google，但在这种情况下看起来这些网站只是根据希望进行身份验证的人的电子邮件地址来确定身份验证提供程序。因此，网站不会向人 select 询问身份验证提供程序，而是询问电子邮件地址，然后确定用户可以使用哪个身份验证提供程序。所以顺序是这样的：
- 1) 用户输入电子邮件地址（或用户 ID）
- 2) 服务器使用电子邮件地址/用户 ID 查找身份验证提供程序
3) 服务器显示用户可以select 来自
的身份验证提供程序列表
我的理解正确吗？
OpenID Provider Issuer Discovery 是一个可选的发现服务，依赖方通过带外机制知道 OP 的发布者位置。或者使用需要提供网站的webfinger
resource = 作为发现请求主题的目标最终用户的标识符。
host = 托管 WebFinger 服务的服务器。
rel = URI 标识正在请求其位置的服务类型。
恕我直言，提供的 example from RFC 7033 具有误导性。许多供应商并没有很好地实现从和“carol@example.com”中确定发行者。 （至少我能找到的）
我tried a few email addresses只能继续发送回复。
（此外，该示例显示了一个简单的 http 获取，但 OpenID Connect Discovery 需要 https）
我确实收到了“will@willnorris.com”来发送回复。 （参见 https://indieweb.org/WebFinger Will Norris 的贡献）
我也很喜欢使用 OpenID Connect webfinger 发现，这很方便也是一个安全问题。
我能够根据日期为 2010 年的条目执行 some discovery on an bradfitz@gmail.com，但并不像示例中所述的 webfinger 查询那么简单。
也许其他人会回应。
通常，网站必须注册（客户端 ID），这可以通过他们希望与之合作的每个 OpenID 连接提供商进行 dynamically。
So it sounds like example.com does not yet know which OpenID connect provider can authenticate Carol?
你是对的。 WebFinger 协议的作用是确定与 OpenID 连接标识符关联的 OpenID 连接提供程序。
当站点显示“使用 Github 进行身份验证”时，它的 OpenID 连接提供程序已被硬编码 (Github)，并且未实现 WebFinger。
在
Suppose Carol wishes to authenticate with a web site she visits using OpenID Connect. She would provide the web site with her OpenID Connect identifier, say carol@example.com. The visited web site would perform a WebFinger query looking for the OpenID Connect provider.
听起来 example.com 还不知道哪个 OpenID 连接提供商可以对 Carol 进行身份验证？它必须使用 Carol 的电子邮件地址作为查找键来找出哪些 OpenID Connect 提供商可以对她进行身份验证？
很多网站都有 Authenticate with Github 或 Authenticate with Google，但在这种情况下看起来这些网站只是根据希望进行身份验证的人的电子邮件地址来确定身份验证提供程序。因此，网站不会向人 select 询问身份验证提供程序，而是询问电子邮件地址，然后确定用户可以使用哪个身份验证提供程序。所以顺序是这样的：
- 1) 用户输入电子邮件地址（或用户 ID）
- 2) 服务器使用电子邮件地址/用户 ID 查找身份验证提供程序
3) 服务器显示用户可以select 来自
的身份验证提供程序列表我的理解正确吗？
OpenID Provider Issuer Discovery 是一个可选的发现服务，依赖方通过带外机制知道 OP 的发布者位置。或者使用需要提供网站的webfinger
resource = 作为发现请求主题的目标最终用户的标识符。
host = 托管 WebFinger 服务的服务器。
rel = URI 标识正在请求其位置的服务类型。
恕我直言，提供的 example from RFC 7033 具有误导性。许多供应商并没有很好地实现从和“carol@example.com”中确定发行者。 （至少我能找到的）
我tried a few email addresses只能继续发送回复。 （此外，该示例显示了一个简单的 http 获取，但 OpenID Connect Discovery 需要 https）
我确实收到了“will@willnorris.com”来发送回复。 （参见 https://indieweb.org/WebFinger Will Norris 的贡献）
我也很喜欢使用 OpenID Connect webfinger 发现，这很方便也是一个安全问题。
我能够根据日期为 2010 年的条目执行 some discovery on an bradfitz@gmail.com，但并不像示例中所述的 webfinger 查询那么简单。
也许其他人会回应。
通常，网站必须注册（客户端 ID），这可以通过他们希望与之合作的每个 OpenID 连接提供商进行 dynamically。
So it sounds like example.com does not yet know which OpenID connect provider can authenticate Carol?
你是对的。 WebFinger 协议的作用是确定与 OpenID 连接标识符关联的 OpenID 连接提供程序。
当站点显示“使用 Github 进行身份验证”时，它的 OpenID 连接提供程序已被硬编码 (Github)，并且未实现 WebFinger。