ID Token validation bypasses rule #2 if Issuer is not configured

Describe the bug
ID Token validation succeeds without enforcing OpenID Connect Core Section 3.1.3.7 rule 2 if Issuer is not specified in the configuration.

To Reproduce

1. Configure the OIDServiceConfiguration per the README instructions "by specifying the endpoints directly", including the authorizationEndpoint and tokenEndpoint but not the issuer.
   
2. ID Token Issuer cannot be validated since the configuration does not specify an expected Issuer.
   Thus, the code skips the validation altogether when issuer is nil.
   

Expected behavior
The OpenID Connect Core Section 3.1.3.7 rule 2 should be enforced unconditionally.
To achieve this, perhaps Issuer should be required in OIDServiceConfiguration?

Additional context
For example, if using Discovery, an Issuer is required, thus ID Token validation is enforced as expected.
However, if specifying the configuration directly (not using Discovery) and an Issuer is not specified, ID Token validation silently succeeds without enforcing rule 2. I know that I personally found this unexpected, and I wonder if others would as well? I believe the spec is fairly unequivocal that rule 2 must be enforced, regardless of whether Discovery was used...

The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.

Since Discovery is optional, I believe "typically obtained" may be just a helpful hint? It seems to me that using Discovery was not intended to be a required precondition for performing ID Token Issuer validation.
...which also makes me question the accuracy of the code comment...

// Validates that the issuer in the ID Token matches that of the discovery document.

Start in Source/OIDAuthorizationService.m around line 416 and review the README's direct-endpoint configuration instructions. Compare the current issuer handling with OpenID Connect Core Section 3.1.3.7 rule 2, and determine how direct configuration should behave when no issuer is supplied; done means issuer validation cannot be silently bypassed.