Thanks for the feedback. More below...
> -----Original Message-----
> From: Pawel Kowalik <pawel.kowa...@denic.de>
> Sent: Tuesday, December 6, 2022 4:12 AM
> To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-
> 19.txt
>
> Caution: This email originated from outside the organization. Do not click
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> Hi Scott,
>
> Thanks for the progress on that.
>
>
> I have the following remarks:
>
> - 3.1.1 refers to "Access Token" in RFC9068 instead of RFC6749. I think this
> might be misleading to exclude opaque access tokens just by redefining it in
> the
> terminology. If the intention is to limit to "JWT Access Token" then I would
> state
> it in explicit way. If it was not the intention then I would define a second
> term
> "JWT Access Token" and then refer to it where appropriate (see remarks to
> Section 6 below).
[SAH] 3.1.1 describes "Access Token" using references from both 6749 and 9068.
It's covered.
> - I would rename the section 3.1.5. "Specialized Claims for RDAP" to
> "Specialized Claims and Authorization Scope for RDAP" (see below remarks to
> section 6.1)
[SAH] OK, makes sense.
> - in the Section 3.1.3 the Sequence diagram for session-oriented client
> should
> also contain RDAP server <-> OP interactions to correspond to the sequence
> diagram of token-oriented clients
[SAH] OK.
> - in the Section 4.1 I propose to add an additional member to the object in
> openidcProviders array:
>
> - "additionalAuthorizationQueryParams" being an object where each member
> represents query parameter name and value is the query parameter value
> This metadata will allow Token-Oriented Client to trigger authorization
> with a
> specified OP through Proxy OP, even if the iss and authorization endpoints
> are
> same. With Keycloak as example this can be controlled with "kc_idp_hint"
> parameter, so the example configuration would be:
>
> "openidcProviders":
> [
> {
> "iss": "https://secure-
> web.cisco.com/1qTpGgvOW0O1IaI0PV07VJOt4JaNNTkdi-
> AvAhv3Wp4mF7rRuTcjEJ_leMZoez112c1Atkf2PO3rgB4na-
> Z5QDbPI5VqhnmYMV0ZW4XrWDJbweHswBJkznKyK3pY8PN8-fx-Bm9EnN-
> 5sKFRu35KKGIlU2masFNMkcEcqVzNugSp9lmz_-
> 0k5eydMRr5Co4TIFhwzWJNkSVXc85nyOazgjgK2vrbF88bIKCirXHUujUQ4XzZkJXW
> B1ehJ9ZZflrTQlqSpaBKl_9XPJ7ZsdAiYrHEHgSntsTbZBhZnFTchaDaAfdPhjwkiMv3
> AE1v21nXS/https%3A%2F%2Flocal-idp.rdap.example.com",
> "name": "Example Public IDP",
> "additionalAuthorizationQueryParams": {
> "kc_idp_hint": "examplepublicidp"
> }
>
> }
>
> ]
[SAH] OK.
> - the Section 5.3 is generic, not depending on client type, so it should
> move to
> Section 4
[SAH] Agreed, I missed that one.
> - same applies to Section 5.7
[SAH] Agreed.
> - in OAuth2 the authorization is done using scopes. I think in the Section
> 6.1 the
> RP should always require scope "rdap". Also the usage of
> additionalAuthorizationQueryParams shall be added here.
>
> - in 6.1 it may be necessary to add also that the OP SHOULD include the
> RDAP
> server in the "aud" claim of the issued token. Alternatively RDAP server may
> choose to ignore the "aud" claim or exchange the token (as described in the
> section 7)
[SAH] OK.
> - we discussed that we do not care that much about remote OPs, however the
> issue of access_token coming from an unknown OP remains. My proposal for a
> simple solution would be just to require a query parameter "OP Issuer
> Identifier" with each RDAP query for non-default OP server. This would be an
> add to 6.2
[SAH] The document already includes the "farv1_iss" query parameter that's
used with a login query. It can be used in this context as needed. Are you
suggesting that the document should include support for a client sending a
"farv1_iss" query parameter with a (for example) domain query such that the
RDAP server will start a session-oriented login process prior to processing
the domain query? If not that, are you suggesting that receipt of a
"farv1_iss" query parameter will simply identify the issuer to the RDAP server
so that the RDAP server can attempt to process the access token received from
a token-oriented client? The latter makes more sense to me.
I see value in remote OPs. In the ICANN registry/registrar world, I fully
believe there is room for entities like law enforcement, security researchers,
intellectual property interests, and similar "communities of interest" to
deploy and operate identity providers for their members. That model scales
better than every registry/registrar RDAP server operator having to operator
their own OP and issue credentials to every person who wants access to their
service. If they do that, they might as well just issue user names and
passwords for use with HTTP Basic authentication.
> - the section 6 should have a subsection about access token validation
> including:
>
> - processing of "OP Issuer Identifier" query parameter and (optional)
> token
> introspection with OP or validation of the JWT access token - this would be
> mainly reference to OAuth2 RFCs
>
> - checking "rdap" scope in the access token
>
> - optional request for User Claim (as needed by the RDAP server) with an
> indication about performance implications and hint for caching
>
> - I would also add token refresh consideration to the Section 6, namely that
> the
> RP needs to take care about refreshing the token as necessary before sending
> requests to RDAP server
[SAH] OK, this makes sense.
> - Section 7 only applies to Token-Oriented Clients, so it belongs under
> Section 6
[SAH] Agreed. Thanks again!
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
