Is documentation correct about OIDC_ISS_ENDPOINT?

[dollarklavs]

The OIDC_ISS_ENDPOINT documentation states that discovery is at OIDC_ISS_ENDPOINT + /.well-known/openid-configuration/. That would indicate that one should include the mount point of the oauth2_provider.urls right?

But ConnectDiscoveryInfoView uses reverse to get the path of the oauth2_provider:authorize, oauth2_provider:token, oauth2_provider:user-info, oauth2_provider:jwks-info which results in the doubling of the mount point info.

So a if oauth2_provider.urls is mounted at /some-initial-path/o all the endpoints, except issuer, included in the response has doubled the mount point information. So if the OIDC_ISS_ENDPOINT is http://localhost:8001/some-initial-path/o the issuer will be http://localhost:8001/some-initial-path/o but authorization_endpoint will be http://localhost:8001/some-initial-path/o/some-initial-path/o/authorize/. Same pattern for token_endpoint, userinfo_endpoint, and jwks_uri

Looking at the tests, there seems to be a little ambivalence about the topic. See below
https://github.com/jazzband/django-oauth-toolkit/blob/9d2aac2480b2a1875eb52612661992f73606bade/tests/test_oidc_views.py#L15

test_get_connect_discovery_info expects a url without a path and test_get_connect_discovery_info_without_issuer_url expects a url with a path /o (the default oauth2 path?).

Anyways - I'm confused. Can anyone clarify if OIDC_ISS_ENDPOINT should just be the root url of the Django app or if it should include the mount point of the oauth2_provider.urls?

EDIT:
It looks as if the OIDC specification mentions this. The correct pattern should follow the django_oauth_toolkit documentation. So OIDC_ISS_ENDPOINT + /.well-known/openid-configuration should resolve.
If this is true, then the test test_get_connect_discovery_info should expect http://localhost/o instead of http://localhost as issuer - I think.

EDIT2:
If OIDC_ISS_ENDPOINT is defined, couldn't it be located somewhere else (another domain) than where ConnectDiscoveryInfoView is located? If yes, isn't it then a mistake to base the location of authorization_endpoint, token_endpoint, userinfo_endpoint, and jwks_uri on the use of reverse for the url patterns on the same host where ConnectDiscoveryInfoView is located.
Why not just hardcode the endpoints to OIDC_ISS_ENDPOINT + {/authorize/, /token/, /userinfo/, o/.well-known/jwks.json}?
Or urlparse OIDC_ISS_ENDPOINT and use the scheme + netloc + reverse of all the endpoints to fill the output of ConnectDiscoveryInfoView.