The definition of SessionNotOnOrAfter element in SAML Core is along the lines of what you'd expect. From section 2.7.2 on <AuthnStatement>:
SessionNotOnOrAfter [Optional]
Indicates an upper bound on sessions with the subject derived from the enclosing assertion. The time value
is encoded in UTC, as described in Section 1.3.3. There is no required
relationship between this attribute and a NotOnOrAfter condition
attribute that may be present in the assertion. It's left to profiles
to provide specific processing rules for relying parties based on this
attribute.
Similarly, the definition of AuthnInstant in Core is pretty straightforward. In the same section 2.7.2:
AuthnInstant [Required]
Specifies the time at which the authentication
took place. The time value is encoded in UTC, as described in Section
1.3.3.
Therefore from a perspective of validation of a SAML message as an XML document subject to certain rules described in Core portion of the SAML spec, the answers to your questions are:
Does this condition represent an AuthN statement which is instantly
invalid?
Answer: no, it doesn't.
What does the SAML standard say, if anything, about a
SessionNotOnOrAfter being exactly equal to AuthnInstant?
Answer: nothing
There are multiple kinds of rules and associated validation steps that may/should/must be performed by a relying party on a SAML message. The structural rules are described in the Core portion of the SAML spec but the behavioral rules are described in the Profiles.
In SAML a particular profile addresses how the assertions,protocols and bindings can be used in solving specific use cases. If the individual elements of SAML message are bricks, Core portion of SAML talks about shape, size and color of bricks whereas a particular profile in Profiles portion describes how to use the bricks to build a specific house. What is the right profile that would govern here?
While some SAML messages can be routed via SOAP over HTTP using rules documented and specified by the SOAP-specific bindings and appropriate profiles in SAML protocol, WSS4J is in a different ecosystem of standards. The behavior of WSS4J is governed by WS-Security. After all, WSS4J stands for Web Services Security for Java. In WS-Security, SAML tokens can be transmitted in a SOAP message based on an a profile of WS-Security rather than a profile of SAML. The appropriate WS-Security profile is WS-Security SAML Token Profile 1.1. Here's what it says about validating the SAML token embedded in a SAML message:
3.5 Subject Confirmation of SAML Assertions
Any processor of SAML assertions MUST conform to the required
validation and processing rules defined in the corresponding SAML
specification including the validation of assertion signatures, the
processing of <saml:Condition> elements within assertions, and the
processing of <saml2:SubjectConfirmationData> attributes.
[SAMLCoreV1] defines the validation and processing rules for V1.1
assertions, while [SAMLCoreV2] is authoritative for V2.0 assertions.
Translation: the structural rules in SAML Core portion of SAML specification still apply. The behavioral rules are dictated by WS-Security SAML Token Profile and this profile does not mention anything with respect to SessionNotOnOrAfter or AuthnInstant.
