Hi Roman, thanks for your review feedback.
> On 21. Aug 2020, at 16:43, Roman Danyliw <[email protected]> wrote: > > Hi! > > I conducted an another AD review of > draft-ietf-oauth-jwt-introspection-response-09. As background, -07 of this > document went to IESG Review and the document was brought back to the WG to > address the DISCUSS points. > > Below is my feedback which can be addressed concurrently with IETF LC. > > ** Section 5. I want to clarify what are the permissible members of > token_introspection. The two relevant text snippets seem to be: > > (a) "token_introspection A JSON object containing the members of the > token introspection response, as specified in the "OAuth > Token Introspection Response" registry established by > [RFC7662] as well as other members." > > (b) "Claims from the "JSON Web Token Claims" registry that are > commonly used in [OpenID.Core] and can be applied to the > resource owner MAY be included as members in the > "token_introspection" claim." > > -- Per (a), Recommend citing the IANA sub-registry directly -- > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response > (and not the "as specified in the "OAuth Token Introspection Response" > registry established by [RFC7662]") done > > -- Per (a), "... as well as other members", what members is this referencing? > Is that (b)? Recommend being clear upfront on which exact registries are > the sources of valid members. I reworked the whole paragraph (hrefs for registries not shown). As specified in section 2.2. of [RFC7662], specific implementations MAY extend the token introspection response with service-specific claims. In the context of this specification, such claims will be added as top-level members of the token_introspection claim. Response names intended to be used across domains MUST be registered in the OAuth Token Introspection Response registry defined by [RFC7662]. In addition, claims from the JSON Web Token Claims registry established by [RFC7519] MAY be included as members in the token_introspection claim. They can serve to convey the privileges delegated to the client, to identify the resource owner or to provide a required contact detail, such as an e-Mail address or phone number. When transmitting such claims the AS acts as an identity provider in regard to the RS. The AS determines based on its RS-specific policy what claims about the resource owner to return in the token introspection response. Does this work for you? > > -- Per (b), "... commonly used in [OpenId.Core]", what are those > specifically? Is that claims registered in > https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is > [OpenID Connect Core 1.0]? Recommend being unambiguous in which claims are > permitted by pointing the IANA registry. > > -- If I'm understanding right that the source comes either from > oauth-parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what > happens if it isn't one of those? Every implementation is also free to use their own specific claims. This is defined in section 2.2. of RFC > > ** Section 5. Per " The AS MUST ensure the release of any privacy-sensitive > data is legally based", recommend also including a forward reference to > Section 9 done best regards, Torsten. > > Regards, > Roman > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
