OID4VC: Decouple authorization server from issuance

Currently the /token endpoint, which is an authorization server function, is included as part of the issuer functionality - monolithic design. Decoupling authorization from issuance will support the following goals:

1. Alignment with OAuth2 design patterns.
2. Enhance the security of the solution.
3. Simplify the development of additional authentication options (see below).
4. Lay the groundwork to enable the integration of the issuer to third party authorization servers.

The python library authlib can be used to help with the development of the standalone authorized server - https://github.com/authlib/authlib. An alternative possibility is https://github.com/oauthlib/oauthlib

The following core features will need to be developed in support of the oid4vci pre authorized flow - base functionality.

• Pre-authorized code grant
• Token and refresh token (supported by authlib)

Future development tasks can then extend the functionality of the authorization server.

• OAuth 2.0 Demonstrating Proof of Possession (DPoP): RFC 9449. (open issue and tagged as a feature for authlib)
• OAuth 2.0 Attestation-Based Client Authentication IETF DRAFT
• OAuth 2.0 Pushed Authorization Requests RFC: 9126 (open issue and tagged as a feature for authlib)
• OID4VCI authorization flow (supported by authlib)

Start by locating the issuer implementation of the /token endpoint and reviewing how authorization and issuance are currently coupled. Define the boundaries for a standalone authorization server, then verify support for the OID4VCI pre-authorized code grant, token, and refresh-token flow; the issue does not name specific files or tests.