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]
