“iss” is the primary identifier for who issued a JWT, and hence for finding that entity’s public keys to verify a JWS containing the JWT.
RFC7519 “JWT” section 5.3 “Replicating Claims as Header Parameters”<https://www.rfc-editor.org/rfc/rfc7519.html#section-5.3> explicitly talks about duplicating “iss” (and “aud” and “sub”) from a JWT body into the header of a JWE as it can be useful “to determine whether and how to process the JWT before it is decrypted”. The section only talks about encrypted JWTs. However, those details are equally useful to determine whether and how to process a JWT before it is verified – but the duplication isn’t necessary as the claims are available in the payload. So your library should provide claims access before verification. Perhaps the JWT design isn’t ideal, but that’s the way it is. I guess you would offer a separate interface specifically for peeking at the unverified claims, and perhaps restrict that to an allowlist of claims. That might limit the risk of insecure use. // Peek at selected claims (“iss”, “aud”, “sub”) before the JWT has been verified Map<String,Object> unverifiedClaims() -- James Manger General From: jose <[email protected]> on behalf of Les Hazlewood <[email protected]> Date: Friday, 13 October 2023 at 5:55 am To: [email protected] <[email protected]> Subject: [jose] JWS signature verification and claims payload You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Hello folks - I hope someone can help answer a quick question: https://datatracker.ietf.org/doc/html/rfc7515#section-5.2 does not make any indication if a Claims payload may be parsed before signature/MAC verification. I am a JOSE library author/maintainer and I've had application developers request the ability to look at information in a Claims payload to help find the key used to verify the signature/MAC. Their concerns are that an Identity Provider may use a key id (kid) in the header that is not guaranteed to be globally unique, and they may need other information in the Claims (e.g. issuer) to help them locate the appropriate key. My response was that there are many other options like jku, jwk thumprints as key ids, x5t, etc, that all mitigate this concern, and I dislike parsing payloads that haven't been cryptographically verified due to potential security issues otherwise. But they said those additional headers are only relevant if if the IdP actually uses those values, and if not, they still might need to look in the claims. What is the JOSE committee's stance on parsing the claims before signature verification? Thank you kindly, Les
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
