On Mon, Jan 24, 2022 at 02:43:40PM +0000, Hollenbeck, Scott wrote:
> [SAH] The best thing we can do is to explain the situation in
> Section 3.1.3.1. What's there now needs to change:
>
> OLD:
> 3.1.3.1. Provider Discovery
>
> An RDAP server/RP needs to receive an identifier from an End-User
> that can be used to discover the End-User's OP. That process is
> required and is documented in the "OpenID Connect Discovery"
> protocol [OIDCD].
>
> PROPOSED NEW:
> 3.1.3.1. Provider Discovery
>
> An RDAP server/RP needs to be able to map an End-User's identifier
> to an OP. This can be accomplished using the OPTIONAL "OpenID
> Connect Discovery" protocol [OIDCD], but that protocol is not widely
> implemented and can be unreliable. Out-of-band methods are also
> possible and can be more dependable. For example, an RP can support
> a limited number of OPs and maintain internal associations of those
> identifiers with the OPs that issued them. An RP can also ask an
> end-user to identify the OP that issued their identifier as part of
> an RDAP query workflow. An RP MAY use any provider discovery
> approach that is suitable for its operating environment.
>
> How does that sound?
I think this is fine, but one adjustment for the "select an OP" case:
An RP can also ask an end-user to identify the OP that issued
their identifier as part of an RDAP query workflow. In this case,
the RP will need to maintain state for the association between the
user's identifier and the OP in order to process later queries
that rely on passing the access token and user identifier as
authorization parameters.
Alternatively, the RDAP client could pass the issuer value (from the
ID token) instead of the user identifier when doing this sort of
query.
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
