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]> 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]> > *Sent:* Tuesday, February 3, 2026 3:06 PM > *To:* Karen ODonoghue <[email protected]> > *Cc:* JOSE WG <[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]> 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] > To unsubscribe send an email to [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]
