To close the loop on this, I believe you need to add “historical” in per Aaron’s suggested text to reflect the agreed upon state.
I suggest we close this consensus question. Neil can you publish the final version so we can move to WGLC. Thanks for everyone’s contributions. Regards, Karen > On Feb 24, 2026, at 10:39 AM, Neil Madden <[email protected]> wrote: > > So, I think the deadline for this consensus call has passed. > > I can live with Mike/Aaron's suggested text. It drops the word "legitimate" > that was the main cause of contention, I think. For reference the proposed > text is: > > Although there are some use-cases for Unsecured JWS that are not security > vulnerabilities, these are relatively few in number and can easily be > satisfied by alternative means. For example, two of these are in OpenID > Connect [OpenID.Core]: (1) securing unsigned ID Tokens via transmission over > TLS in Section 3.1.3.7 and (2) the use of unsigned request objects in Section > 6.1. The small risk of breaking some of these use-cases is far outweighed by > the improvement in security for the majority of JWS users who may be impacted > by accidental acceptance of the "none" algorithm. > > Brian - can you live with that? > > -- Neil > >> On 4 Feb 2026, at 01:25, Michael Jones <[email protected]> wrote: >> >> I’m good with Aaron’s suggestions. And yes, 3.1.3.7 >> <https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation> >> (item 6) is a better reference. >> >> -- Mike >> >> From: Aaron Parecki <[email protected]> >> Sent: Tuesday, February 3, 2026 5:11 PM >> To: JOSE WG <[email protected]> >> Cc: Karen ODonoghue <[email protected]> >> Subject: [jose] Re: Consensus question on text for "none" in >> draft-madden-jose-deprecate-none-rsa15 >> >> Arguably it was a mistake for OpenID Connect to use alg: none in the first >> place, and would have been better solved by returning the properties in the >> ID token directly in the token endpoint response like I describe here: >> https://drafts.aaronpk.com/openid-simplified-userinfo-response/draft-openid-simplified-userinfo-response.html >> But that ship sailed long ago and here we are. >> >> I like the direction of the text Mike proposes. Can we add "historical" in >> there as well? >> >> Although there are some historical use cases for Unsecured JWS that are not >> security vulnerabilities, these are relatively few in number and can easily >> be satisfied by alternative means. For example... >> >> Also, wouldn't Section 3.1.3.7 be a better reference than Section 2 though? >> That is where it is explained that the RP can skip the JWT signature >> validation step even if the ID token is signed. So basically saying the RP >> can treat the JWT as an alg:none JWT even if it was signed. >> >> Aaron >> >> >> On Tue, Feb 3, 2026 at 4:42 PM Michael Jones <[email protected] >> <mailto:[email protected]>> wrote: >> Thanks for this discussion and for the attempts to find a consensus position >> that all can live with to move the drafts forwards. >> >> For context, in this message >> https://mailarchive.ietf.org/arch/msg/jose/UJux4NgsC7tOVst0Qo0vkvvAcEM/ on >> July 24, 2025, I had suggested inclusion of the following wording so as to >> provide a balanced treatment of the subject: >> >> 1.1. >> <https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#section-1.1>The >> 'none' algorithm >> <https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#name-the-none-algorithm>: >> After the sentence beginning “Although there are some legitimate use-cases >> for Unsecured JWS”, I suggest adding this text: >> One of the legitimate use cases for Unsecured JWSs is OpenID Connect ID >> Tokens secured by sending them over a TLS connection, as described in >> Section 2 of [OpenID.Core]. Another legitimate use is unsigned request >> objects, as described in Section 6.1 of [OpenID.Core]. >> >> That way both known unsafe and known safe uses of “alg”: “none” would be >> described in the document – which is my core ask. (Currently only misuses >> of it are referenced.) >> >> I believe that Brian’s suggestion to possibly use a different description >> than “legitimate” may provide us a way forward towards a consensus position. >> Let me take a crack at alternative language I could live with. The draft >> currently says: >> >> Although there are some legitimate use-cases for Unsecured JWS, these are >> relatively few in number and can easily be satisfied by alternative means. >> The small risk of breaking some of these use-cases is far outweighed by the >> improvement in security for the majority of JWS users who may be impacted by >> accidental acceptance of the "none" algorithm. >> >> I could live with this treatment of my suggestion, by instead changing that >> paragraph to: >> >> Although there are some use-cases for Unsecured JWS that are not security >> vulnerabilities, these are relatively few in number and can easily be >> satisfied by alternative means. For example, two of these are in OpenID >> Connect [OpenID.Core]: (1) securing unsigned ID Tokens via transmission over >> TLS in Section 2 and (2) the use of unsigned request objects in Section 6.1. >> The small risk of breaking some of these use-cases is far outweighed by the >> improvement in security for the majority of JWS users who may be impacted by >> accidental acceptance of the "none" algorithm. >> >> If people want to further improve the wording, great. As long as a factual >> treatment of the safe uses of “alg”: “none” by OpenID Connect is included, >> I’ll probably be good with it. >> >> Thanks all, >> -- Mike >> >> From: Filip Skokan <[email protected] <mailto:[email protected]>> >> Sent: Tuesday, February 3, 2026 3:06 PM >> To: Karen ODonoghue <[email protected] <mailto:[email protected]>> >> Cc: JOSE WG <[email protected] <mailto:[email protected]>> >> Subject: [jose] Re: Consensus question on text for "none" in >> draft-madden-jose-deprecate-none-rsa15 >> >> I prefer Option 2 both with or without the slight wording changes suggested >> by Neil and Brian in this thread. >> >> S pozdravem, >> Filip Skokan >> >> >> On Tue, 3 Feb 2026 at 06:41, Karen ODonoghue <[email protected] >> <mailto:[email protected]>> wrote: >> JOSE Working Group Members, >> >> We are following up on discussions at IETF 124 on >> draft-madden-jose-deprecate-none-rsa15. >> >> Firstly, thank you to Neil for your work on this draft and to those who have >> provided review thus far. >> >> The one remaining outstanding item for this draft is whether to add text to >> capture legitimate use cases of "none" as suggested by Mike in his review >> https://mailarchive.ietf.org/arch/msg/jose/Z4IJGxKubk81LK8ZKYjY3prPmis/ >> >> This was discussed in Montreal, with views both for and against this >> addition, and we agreed to follow up with discussion on list. With that in >> mind, we’d like to ask for a rough consensus on which of the following two >> choices you prefer: >> >> Option 1) Change the text in Section 1.1 to include the following suggested >> text: >> "One of the legitimate use cases for Unsecured JWSs is OpenID Connect ID >> Tokens secured by sending them over a TLS connection, as described in >> Section 2 of [OpenID.Core]. Another legitimate use is unsigned request >> objects, as described in Section 6.1 of [OpenID.Core].” >> >> Option 2) Leave the text in Section 1.1 as it currently is: >> "Although there are some legitimate use-cases for Unsecured JWS, these are >> relatively few in number and can easily be satisfied by alternative means.” >> >> In the absence of a compromise on some alternative text that is agreed to by >> rough consensus, we will need to make a choice between the two above >> approaches. >> >> Please respond to this email with your preference for Option 1 or Option 2. >> Please provide a short rationale. so we can capture the view of the Working >> Group and move this draft forward. >> >> This consensus call will last for two weeks ending on Tuesday, 17 February >> 2026. >> >> Thanks, >> JOSE 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] <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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
