Oh, and as fate would have it, these specifications were just published as ISO standards yesterday. See the blog post about it<https://self-issued.info/?p=2573> and my LinkedIn post<https://www.linkedin.com/posts/selfissued_openid-connect-specifications-published-as-activity-7246927008935411714-W5wa/>. Prohibiting the use of "none" would break these new ISO specifications too.
From: Michael Jones Sent: Wednesday, October 2, 2024 9:46 AM To: Karen ODonoghue <[email protected]>; JOSE WG <[email protected]> Subject: RE: [jose] Call for Adoption: draft-madden-jose-deprecate-none-rsa15 As had been previously discussed, I request that this draft be split into two before adoption is considered - one for each algorithm. The discussions on "RSA1_5" and "none" are likely to be nearly distinct and it would be helpful to be able to consider each question independently. For what it's worth, deprecating "none" would be a breaking change to OpenID Connect. Here are few examples of the safe use of "none": * https://openid.net/specs/openid-connect-core-1_0.html#RequestObject: The Request Object MAY be signed or unsigned (unsecured). When it is unsecured, this is indicated by use of the "none" algorithm [JWA] in the JOSE Header. * https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata: In "id_token_signing_alg_values_supported" - The value "none" MAY be supported but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow). * https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata: In "userinfo_signing_alg_values_supported" - The value "none" MAY be included. * https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata: In "request_object_signing_alg_values_supported" - Servers SHOULD support "none" and "RS256". * https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata: In "request_object_signing_alg" - The value none MAY be used. "none" is used to indicate that there is no signature on a base64url-encoded data structure. There are plenty of use cases where security doesn't require signed data, but it's nonetheless valuable to represent the data in a URL-safe manner. These are such cases. In my view, we shouldn't break this usage, but I realize that that's a point of discussion. In conclusion, I believe that the draft should be split into two and then adoption should be considered for each separately. I oppose adoption in its present form. Thank you, -- Mike -----Original Message----- From: Karen ODonoghue <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 2, 2024 3:31 AM To: JOSE WG <[email protected]<mailto:[email protected]>> Subject: [jose] Call for Adoption: draft-madden-jose-deprecate-none-rsa15 JOSE working group members, The following document has been presented to the jose working group for consideration and been discussed at previous meetings. We have agreed to issue a call for adoption. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-madden-jose-deprecate-none-rsa15%2F&data=05%7C02%7C%7C167f8a39da944d7125cc08dce2cd928a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638634619756190095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rir9QxQd%2FnOzn7Pw1vx%2BZXjxhOvb8s%2BhC7ZdWDxNR3E%3D&reserved=0<https://datatracker.ietf.org/doc/draft-madden-jose-deprecate-none-rsa15/> Please respond to this call for adoption with your thoughts on whether or not the working group should adopt this document as a basis for this work. Also, please indicate your willingness to review and/or contribute to the document. The call for adoption closes on Friday 18 October. Thanks, Karen (for the JOSE co-chairs) _______________________________________________ jose mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
