# SSWG-0029: JWSETKit **URL:** \ **Category:** Proposals\ **Created:** [January 29, 2024, 2:21am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685 "2024-01-29T02:21:30Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\ **Post date:** [January 29, 2024, 2:21am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/1 "2024-01-29T02:21:30Z")
The review of [SSWG-0029: JWSETKit](https://github.com/swift-server/sswg/blob/main/proposals/0029-jwsetkit.md) begins now and runs for two weeks, until February 12th, 2024. * * * Reviews are an important part of the Swift Server Work Group [incubation process](https://www.swift.org/sswg/incubation-process.html). All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager ([via email](mailto:ktoso@apple.com)) or direct message in the Swift forums. The package is being proposed at the **Sandbox** maturity level. Please note the Maturity Justification inside the proposal for details and indicate which you find more appropriate as part of your review. ## What goes into a review of a proposal? The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, become listed on the Swift Server Ecosystem [index page](https://www.swift.org/sswg/#projects). When reviewing a proposal, here are some questions to consider: - What is your evaluation of the proposal and its APIs/implementation? - Is the problem being addressed relevant for the wider Swift on Server ecosystem? - Does this proposal fit well with the feel and direction of the Swift Server ecosystem? - If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those? - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Konrad 'ktoso' Malawski Review Manager ---
**Author:** ![jaleel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jaleel/32/45076_2.png) [@jaleel](https://forums.swift.org/u/jaleel)\ **Post date:** [January 30, 2024, 9:12am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/2 "2024-01-30T09:12:57Z")
Not sure if it's correct place or should start an issue on Github, but will write first here. Was going through the code yesterday as library is indeed needed, and noticed it's using `AnyCodable`. Could be my personal tastes, but think it should be more strict here, cause there are lines in `JSONWebValueStorage` which _breaks_ type contract for me, like: ```swift private var storage: [String: AnyCodable] switch value { case let value as any JSONWebFieldEncodable: storage[key] = .init(value.jsonWebValue) case let value as any Decodable: storage[key] = .init(value) default: remove(key: key) assertionFailure("Unknown storage type") } ``` `AnyCodable` is both `Encodable` **and** `Decodable`, why passing just `Encodable` **or** `Decodable` should work then? 🤔 Removing `AnyCodable`, passing generic type and being strict on types feels like a better choice in Swift ecosystem, as `JSONWebValueStorage` is public and exposed for others to use. ---
**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\ **Post date:** [January 30, 2024, 12:58pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/3 "2024-01-30T12:58:35Z")
SSWG reviews are primarily about the criteria mentioned on [Swift.org - SSWG Incubation Process](https://www.swift.org/sswg/incubation-process.html) as "requirements". Having that said, technical best practices are part of that. Any feedback / reviews that can help access and improve the library are welcome process wise. ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [January 30, 2024, 6:31pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/4 "2024-01-30T18:31:51Z")
> [@jaleel](#): > > `storage[key] = .init(value.jsonWebValue)` Thanks @jaleel for you feedback. Please check changes in this branch [https://github.com/amosavian/JWSETKit/tree/generic-codable](https://github.com/amosavian/JWSETKit/tree/generic-codable). ---
**Author:** ![jaleel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jaleel/32/45076_2.png) [@jaleel](https://forums.swift.org/u/jaleel)\ **Post date:** [January 31, 2024, 9:41am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/5 "2024-01-31T09:41:30Z")
Will have a look in upcoming days and overall more deeply in codebase. But thanks for quick response! ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [January 31, 2024, 10:45am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/6 "2024-01-31T10:45:59Z")
In general, I am a +1 on incubating a JWT package since JWX is commonly used in server applications (leaving aside that they are often the wrong tool for the job). This package is missing a few minimum requirements though: - From what I can see it hasn't adopted the Swift code of conduct - Longevity: The package appears to be maintained by just @amosavian - Dependencies: The package is using `CryptoSwift` which contains unvetted cryptographic implementations; hence, we avoid using this in any SSWG incubating package. Until we resolve the above issues I personally think we shouldn't go forward with incubating this package. After the issues have been resolved we can send it for another round of review. ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [January 31, 2024, 3:49pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/7 "2024-01-31T15:49:47Z")
Thanks @FranzBusch, - Code of conduct has been added to project. - I'm open to add other maintainers or transfer project to SSWG. - CryptoSwift is used to support PBKDF2 and RSA-PKCS1.5 encryption: - We can use a implementation of PBKDF inside the repo as [oracle-nio](https://github.com/lovetodream/oracle-nio/blob/main/Sources/_PBKDF2/PBKDF2.swift) did. - I can remove RSA-PKCS1.5 support on Linux as `_CryptoExtras` module does not support this padding.. Edit: Please check [GitHub - amosavian/JWSETKit at remove-cryptoswift](https://github.com/amosavian/JWSETKit/tree/remove-cryptoswift) for changes in order to remove `CryptoSwift` ---
**Author:** ![0xTim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/0xtim/32/27968_2.png) [@0xTim](https://forums.swift.org/u/0xTim)\ **Post date:** [January 31, 2024, 5:14pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/8 "2024-01-31T17:14:49Z")
> [@amosavian](#): > > I can remove RSA-PKCS1.5 support on Linux as `_CryptoExtras` module does not support this padding.. I feel this is an issue - having different feature sets for Linux and macOS is likely to cause confusion for users and goes against the ethos of the SSWG of having consistent functionality on all platforms ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [January 31, 2024, 5:54pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/9 "2024-01-31T17:54:51Z")
Hi @0xTim There are few algorithms which are not supported in Apple's Crypto/CryptoExtras: - `PBKDF2` - `RSA1_5` (RSA-PKCS1.5) - `RSA-OAEP-384` - `RSA-OAEP-512` I found no other Swift library than `CryptoSwift` which supports Linux and implements these algorithms. These algorithms are supported by CommonCrypto and BoringSSL and can be added to Crypto with no significant effort. ---
**Author:** ![0xTim](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/0xtim/32/27968_2.png) [@0xTim](https://forums.swift.org/u/0xTim)\ **Post date:** [February 7, 2024, 10:14pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/10 "2024-02-07T22:14:53Z")
Sure but with the current state of things - having different features on different platforms is probably a no go, more than any implementation details IMO ---
**Author:** ![gwynne](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwynne/32/24337_2.png) [@gwynne](https://forums.swift.org/u/gwynne)\ **Post date:** [March 12, 2024, 8:02am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/11 "2024-03-12T08:02:57Z")
I concur with Tim - missing features across platforms feels like a non-starter. [JWTKit v5](https://github.com/swift-server/sswg/pull/102) achieves feature parity via SwiftCrypto, so the baseline seems reasonable. ---
**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\ **Post date:** [March 12, 2024, 8:10am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/12 "2024-03-12T08:10:19Z")
🎩 Chiming in with review manager hat on: Sorry for the long wait here @amosavian. We're voting now and will reach a conclusion shortly. It should be clear though that the criteria for Sandbox are specifically those listed here: [Swift.org - SSWG Incubation Process](https://www.swift.org/sswg/incubation-process.html#minimal-requirements) and there is no part about completeness or feature-set judgement. The feedback of the team is valuable nevertheless though, we have concerns about the feature set, but it is not a requirement of the Sandbox level so it might be accepted nevertheless. ---
**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\ **Post date:** [March 12, 2024, 2:01pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/13 "2024-03-12T14:01:03Z")
We did a round of discussions in the group with regards to this proposal; and general SSWG rules, so allow me to summarize them here. * * * ✅ The SSWG has decided to **accept this proposal** into **Sandbox** maturity level! Specifically, this decision is guided by the project fulfilling all requirements of the [Sandbox](https://github.com/swift-server/sswg/blob/master/process/incubation.md#sandbox-level) level, and has an active active stream of development. ❗ At the same time however, we are concerned about the feature parity between platforms, and going forward we are going to start a discussion and may change SSWG maturity level requirements to reflect that packages should have platform parity. Also, SSWG endorsed projects should prefer the "vetted" SSWG endorsed `SwiftCrypto` package for their cryptography needs when applicable. Since we did not have rules about such parity, or requirements regarding cryptography at the time of this review. We review it using the current rules. If and when we were to adopt a new rule in the maturity levels, we will re-review packages again. Therefore , we would strongly suggest getting this package up to feature parity, either by feature removal (as proposed in [!feat: Remove CryptoSwift (PKCS1.5 encryption support in Linux) · amosavian/JWSETKit@b8256c8 · GitHub](https://github.com/amosavian/JWSETKit/commit/b8256c8ec3852d5d79f8fd17b41eadca0d2cbfd9)), or by figuring out how to implement the missing logic using SwiftCrypto. @lukasa has been open to accepting new algorithms into the "`_CryptoExtras`" package that accompanies SwiftCrypto; so aiming to get an implementation there and use it would be the best outcome here. Another related discussion re algorithms recently happened over here: [[Pitch] OracleNIO: Oracle DB Driver built on SwiftNIO](https://forums.swift.org/t/pitch-oraclenio-oracle-db-driver-built-on-swiftnio/69088) -- specifically discussing `PBKDF2` which could be added to \_CryptoExtras. We'll add the project to the list of SSWG endorsed projects shortly. ---
**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\ **Post date:** [March 12, 2024, 2:18pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/14 "2024-03-12T14:18:00Z")
To clarify to this: PBKDF2 can be added subject to the caveats discussed in the PR linked above. RSA OAEP with the two extended SHA functions should be addable in the current API. RSA encryption with PKCS1v1.5 padding is a potential sticking point. This is a _dangerous_ primitive that is frequently misused. I think we need to seriously ask ourselves whether this is a necessary part of our ecosystem, or whether we can try to hold a line on avoiding even having it. ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [May 4, 2024, 9:46pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/15 "2024-05-04T21:46:23Z")
Hey @lukasa, RSAES-PKCS1-v1.5 would be deprecated soon by [draft-madden-jose-deprecate-none-rsa15-00](https://datatracker.ietf.org/doc/html/draft-madden-jose-deprecate-none-rsa15-00). I'm not sure we should keep it as a deprecated protocol or just remove it as it is unsafe to add it to swift-crypto. ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [August 25, 2025, 11:38am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/16 "2025-08-25T11:38:40Z")
Hey @ktoso (and SSWG team — cc @0xTim@gwynne @lukasa), Quick update on [JWSETKit](https://github.com/amosavian/JWSETKit/releases): - **CryptoSwift removed.** The package now relies solely on `swift-crypto` to address the SSWG guidance to prefer the vetted crypto stack and to keep **feature parity across platforms**. - `RSA1_5` is marked deprecated to address this _dangerous_ primitive that is frequently misused. - **PBKDF2** now uses `_CryptoExtras` rather than CryptoSwift. - **X.509 (**`swift-certificates`**) is opt-in.** To avoid building BoringSSL on Darwin builds unnecessarily (since `swift-certificates` depends on `_CryptoExtras` unconditionally), X.509 support is gated behind the **"X509" package trait** (Swift 6.1+). Enable it like this: ```swift .package(url: "https://github.com/amosavian/JWSETKit", from: "0.26.0", traits: ["X509"]) ``` - This keeps default build times and binary size down on Apple platforms when X.509 isn’t needed. - **New (draft) standards support:** These changes align with the acceptance note’s recommendations (use `swift-crypto` and ensure parity). Feedback welcome if any improvement is possible to done. ---
**Author:** ![Joannis\_Orlandos](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joannis_orlandos/32/732_2.png) [@Joannis\_Orlandos](https://forums.swift.org/u/Joannis_Orlandos)\ **Post date:** [August 25, 2025, 10:07pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/17 "2025-08-25T22:07:11Z")
Awesome work! And Thanks for the update ---
**Author:** ![EZabolotniy](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ezabolotniy/32/28351_2.png) [@EZabolotniy](https://forums.swift.org/u/EZabolotniy)\ **Post date:** [December 16, 2025, 2:58pm UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/18 "2025-12-16T14:58:59Z")
Hey @amosavian, is there a way to retrieve public keys from a JWKS endpoint, or is it supposed to be implemented separately—something like a JWKProvider that fetches the keys and also implements caching? ---
**Author:** ![amosavian](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/amosavian/32/2253_2.png) [@amosavian](https://forums.swift.org/u/amosavian)\ **Post date:** [December 17, 2025, 8:04am UTC](https://forums.swift.org/t/sswg-0029-jwsetkit/69685/19 "2025-12-17T08:04:16Z")
Hey @EZabolotniy, There is a `try await JSONWebKeySet(url:)` method in Darwin platforms or when FoundationNetworking can be imported. I will add this method when AsyncHTTPClient is available (e.g. Vapor) but this is a limitation now.