It seems that [`RSA-PSS` in Safari on Mac][1] using [CommonCrypto][2] which uses [corecrypto][3],
follows [FIPS 186-4, Section 5.5, Step (e)][4], restricting [saltLength] to `0 <= saltLength <= hashLength`.

While the [WebCrypto spec][5] references [RFC3447 Section 8.1][6], which as far as I can see doesn't impose any limits on `saltLength`.
At the same time, both Chrome and Firefox allow arbitrary `saltLength` until some limit at which these fail too.

It is entirely possible that:
 (A) I missed something in [RFC3447 Section 8.1][6], and that it does in fact enforce this limit,
 (B) Firefox and Chrome both have different arbitrary limits on `saltLength`.

It is also possible that this is entirely inconsequential, [RFC 3447 Section 9.1, Notes 4][7] states:
> Typical salt lengths in octets are hLen (the length of the output of the hash function Hash) and 0.

So I suppose it's plausible that nobody would/should ever use saltLength > hLen.
In this case, I suppose it would be preferable to refine the webcrypto spec to impose these limits.

Sorry, if this is just an inconsequential discrepancy, I'm not an expert on RSA-PSS.
(And sorry, if this the wrong place, it's hard to tell if it's Firefox, Chrome, Safari og the webcrypto spec)

[1]: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/crypto/mac/CryptoAlgorithmRSA_PSSMac.cpp?rev=238754#L56
[2]: https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60165.120.1/lib/CommonRSACryptor.c.auto.html
[3]: https://opensource.apple.com/source/xnu/xnu-4570.41.2/EXTERNAL_HEADERS/corecrypto/ccrsa.h.auto.html
[4]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
[5]: https://w3c.github.io/webcrypto/#rsa-pss-operations
[6]: https://tools.ietf.org/html/rfc3447#section-8.1
[7]: https://tools.ietf.org/html/rfc3447#section-9.1