Refactor openid4vc library

[waltkb]

Currently, the openid4vc library provides interfaces that are more geared towards being a framework for use in the Wallet Kit than providing the necessary isolated functions as expected by the Issuer API and Verifier API, manifesting itself through needing various hacks to map outside data around the openid4vc library as to being able to run through the flows. This is currently a blocking issue for continuing with the cloud platform.

Classes and implementations thereof like OpenIDCredentialIssuer should not be needed, and no internal representation of state should exist within the library, as this then stops adhering to the definition of library and moves towards being a not flexible enough framework. For example open class CIProvider : OpenIDCredentialIssuer( ... ) with ... being various configuration is not flexible enough for dynamic usage as e.g. in the Cloud platform.

After the refactor, the openid4vc library should (only) provide:

• serializable data classes for protocol requests and responses [probably already fine?]
• isolated functions with state completely being provided through their arguments and the full mutated state being returned
• no interfaces that require implementation of predefined functions (all of this shall be provided from the outside function caller instead of being invoked within the library) -> e.g. currently there are functions in the interface OpenIDCredentialIssuer that have to be implemented, with most of them not being flexible enough to not need hacks to bring in additional data, e.g. doGenerateCredential only having type, did, and nonce as arguments; the nonce not referring to the session state exposed to the library user / caller)
• no hard dependencies to any platforms, web servers, or cryptography libraries (functions should be able to be called no matter what web server is used, should not require platform specific functionality, and cryptographic operations will be done by the library caller outside of the openid4vc library) [mostly already the case?]
• no session and other state handling (call shall be able to define when/how/if to set & remove a session or view the different versions of the session object over time, handle session expiration conditions themselves)
• by not having any internal state (all state provided from outside) all functions should be thread-safe/concurrency-safe

-> Mainly refers to OpenIDCredentialIssuer, OpenIDCredentialWallet, and OpenIDCredentialVerifier.

End deliverable/result is a single Kotlin function (which can already serve as unit test) which contains the function calls that can run through the whole flow (Issuer -> issues -> Wallet -> presents -> Verifier) by passing around the OIDC4VC data objects between functions (not doing real HTTP requests, you can make comments what HTTP endpoint would be called in that place).

[severinstampler]

Maybe we can discuss this directly.
Surely the idea was, that the state management is handled via abstract methods, that are provided by the implementer of the abstract class (as a library user). How the state management is done is up to the implementer and the use case.
For the cloud API, there could be dedicated implementation providing the necessary flexibility to the outside and encapsulating the state management internally.
But anyways, I'm interested to talk about it.

[github-actions]

This issue has been marked as stale.

[taminobaumann]

@severinstampler, can you please check if everything is already resolved and if this item can therefore be closed? Please check if the Linear issue here has also been closed.