1. iat content based on PASSporT issuance time Conflict Analysis against RFC8224 / ATIS-1000074

2. RFC8224 4.1 PASSporT Construction 6.2 Verifier Behavior
Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED).
Using local clock time as “iat” content is allowed if full form is used
6.2 Verifier Behavior
Step 4: Check the Freshness of Date
The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the attacks this prevents, see Section If the full form of the PASSporT is present, the verifier SHOULD compare the "iat" value in the PASSporT to the Date header field value in the request. If the two are different, and the "iat" value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the "iat" value instead of the Date header field value.
For full form, “iat”, Date header content being different is allowed
That “iat” passes freshness check is sufficient

3. ATIS-1000074 5.3.1 PASSporT & Identity Header Verification
The verifier validates that the PASSporT token provided in the Identity header of the INVITE includes all of the baseline claims, as well as the SHAKEN extension claims. The verifier shall also follow the draft-ietf-stirrfc4474bis-defined verification procedures to check the corresponding date, originating identity (i.e., the originating telephone number) and destination identities (i.e., the terminating telephone numbers).
Follows RFC8224, no new mandates regarding date check
5.3.3 Use of the Full Form of PASSporT
Draft-ietf-stir-rfc4474bis supports the use of both full and compact forms of the PASSporT token in the Identity header. The full form of the PASSporT token 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 438 (‘Invalid Identity Header’) errors being generated.
Use of full form mandated

4. Freshness Check during Authentication
RFC PASSPorT Construction
Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED).
Authentication Service = CSCF + STI-AS
Date header check, where?
RFC8224 is agnostic to ATIS split of functionality and therefore any functionality expected by Authentication Service can be implemented - at least theoretically – either in CSCF or in STI-AS.
I would think that anything related with session semantics/network deployment model/services should be responsibility of CSCF and STI-AS should be mainly dealing with generating the signature/PASSporT.
Freshness check from Authentication Service perspective: Whether Date header is “fresh enough” or not depends on network deployment, at which point signature is to be generated, scenario under consideration and all these are session related IMHO.
Some examples:
i- Originating Network signing before call egresses to another Operator, announcement/digit collection already happened (the use case I already presented)
There is a non-negligible difference between Date and current time but it is legitimate. Freshness check should pass.
ii- Intermediary Network signing on behalf of the Originating Network. Originating Network full trusted. Announcement/digit collection happened in Originating Network.
There is a non-negligible difference between Date and current time but it is legitimate. Intermediary Network wouldn’t know about announcement/digit collection but it trusts Originating Network. Freshness check should pass.
iii- Intermediary Network signing on behalf of the Originating Network. Originating Network somewhat trusted. Announcement/digit collection happened in Originating Network.
There is a non-negligible difference between Date and current time but it is legitimate. Intermediary Network wouldn’t know about announcement/digit collection. Based on policy, it decides not to generate a signature.
There could be many more variations but the common point is that the decision would require session level policy/knowledge about origin of the call/trust level associated with the origin etc… I don’t think STI-AS should be aware of such concepts. It is not a session control element.

5. Freshness Check during Authentication
What is the purpose?
If Date is used for “iat” making sure that it is not stale as otherwise it would be rejected during validation
Still problematic as freshness threshold may be different at Verification Service
Any reason why it should be done if “iat” is populated with local time of Authentication Service?