Hi Alissa, Thanks for your review.
We decided to remove the registration requests for OpenID Connect claims from the draft in the latest revision. https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 Those claims are already registered in the JWT Claims registry, which is sufficient for the use cases in our draft. best regards, Torsten. > On 4. Sep 2019, at 17:49, Alissa Cooper via Datatracker <[email protected]> > wrote: > > Alissa Cooper has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Benjamin's DISCUSS point about the IESG being listed as the change > controller for the registry entries. Overall I'd like to understand better the > relationship between these registry entries and future updates to OpenID > Connect (i.e., if the claims in the OpenID spec change, will this registry > automatically need to change as well?). > > I also support Adam's DISCUSS. How are claims like preferred_username > currently > used for the described use case of verifying person data to create > certificates? > > If the linkage with the OpenID Connect 1.0 claims remains in the document, I > think it would be good to add a note in Section 1.1 or a new Section 1.2 to > indicate that the document uses terminology as defined in that spec (e.g., > "End-User," "Relying Party," etc.). > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
