I've asked the OP to create a GitHub issue for this as I don't plan to work this myself. Adding for tracking.
The Asterisk implementation requires a Date header, but it should not.
There was an issue with the standards early on that the IETF defined something called a "compact" form of the PASSporT, where only the signature was sent and all the other parameters were reconstructed from the SIP headers. So in that case there would be no "iat" and the date would come from Date. "shaken" and all the ATIS-defined PASSporTs only use full-form where all the info is in the JSON header/payload. Some people still insist on sending date but the recommendation is not to trust it and not to look at it to determine the date the PASSporT was generated.
6/17/2025 5:20 PM — InterLinked
If you haven't seen already, there is a PR up for this if you're able to test and report back to George: https://github.com/asterisk/asterisk/pull/1270
6/19/2025 10:21 AM — InterLinked
Asterisk PR has been merged, closing this issue as resolved
You must be
5/18/2025 5:03 PM — shane
ATIS-1000074.v003 also states:
5.3.3 Use of the Full Form of PASSporT
IETF RFC 8224 [Ref 13] supports the use of both full and compact forms of the PASSporT in the Identity header.
The full form of the PASSporT shall be used to avoid any potential SIP network element interaction with headers,
in particular the Date header field, which could lead to large numbers of errors being generated (the “iat” value in
the payload that is protected by the signatures should be considered a more reliable indicator of PASSporT
freshness than any time value in the SIP Date header).