NATS Input

Description:

According to the architecture, this service will receive its original input and the trigger to retrieve credentials via NATS. Input will be a credential offering link following this spec: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-offer and the tenantid. The tenantid will be used for storing the credential in the storage service.

Example url: openid-credential-offer://credential_offer=%7B%22credential_issuer%22:%22https://credential-issuer.example.com %22,%22credentials%22:%5B%7B%22format%22:%22jwt_vc_json%22,%22types%22:%5B%22VerifiableCr edential%22,%22UniversityDegreeCredential%22%5D%7D%5D,%22issuer_state%22:%22eyJhbGciOiJSU0Et... FYUaBy%22%7D

URL Decoded:

openid-credential-offer://credential_offer={"credential_issuer":"https://credential-issuer.example.com","credentials":[{"format":"jwt_vc_json","types":["VerifiableCredential","UniversityDegreeCredential"]}],"issuer_state":"eyJhbGciOiJSU0Et...FYUaBy"}

Parse the credential offer object into a native struct for later usage. Make sure all possible fields are covered by parsing.

if none of the offered grant types is pre-authorized_code without the pin required, stop processing and log an error message that a credential with unsupported grant types was offered.

The subscription topic should be chosen initially in a sensible way. Lateron alignment for topic with the Team creating the didcomm connector must be made, but this is outside of the scope of this issue. the subscription topic should be configurable through the configuration.

Acceptance Criteria:

• NATS input is parsed
• (debug) logs are generated
• subscription topic is configurable and config is setup