SDI-X-Adapter ALPHA API specification feedback

# SDI-X-Adapter ALPHA API specification feedback ### General assumptions / questions: - We (as well as other partners) will need to support these API endpoints. Alternatively we could integrate our issuer / verifier components with the SDIx adapter (which in turn exposes the aforementioned API). - **Are all endpoints mandatory?** Certain endpoints (`/keypair`, `/did/{id}`) seem useful but not related to OIDC issuance / presentation functionality? - Overall question, do we envision multi-tenancy / multiple issuer + verifier identities (with different did:web DIDs) being used here? From the issuance endpoint definition, it seems like the issuer identity can be configured. From the presentation endpoint definition, it seems like the verifier can not be specified. ### Question(s) related to `default` endpoint group. --- `/keypair` endpoint - seems to return a new `verificationMethod` (including private key) for each call. The key is associated (via the controller field) with Sdika managed issuer did:web DID. - Is the intention for this method to add a new key to a DID Document? If yes: - The document does not seem to be updated. - Can the identitiy (e.g. `did:web:didserver...:issuer`, `did:web:didserver...:issuer2`) be configured (if this kind of multi-tenancy is envisioned at all) - Is the intention to users to inject a private / public key into the Issuer / Verifier DID Document? - If yes, the key must be provided as an argument - If yes, the DID Document of the issuer would need to be updated - Is it envisioned that all integrating agents **MUST support** this endpoint? Or is it's support optional? --- `/did/{id}` endpoint - seems to allow callers to easily resolve did:web DIDs registered using the `didserver.sdika.we.network` domain. 1. No matter what value we pass as the `id` query param, a DID Document is always returned. The DID Document includes the (potentially invalid) DID in the ID field (e.g. `did:web:didserver.sdika.we.network:issuer_41231231321321312`). All verification material entries are associated with the `did:web:didserver.sdika.we.network:issuer` identifier. The question therefore is if this behaviour is temporary and will be changed, or if this is the intended behaviour. A bit of context on the intended usage patterns for this endpoint would help clarify this question. --- `/vc/{id}` - seems pretty straight-forward, no major questions here. --- `vc/verify` - seems pretty straight-forward, would be good to **settle on the return type**, i.e. we should clearly communicate to the user if and why a credential is valid (e.g. is it expired, revoked, modified [i.e. signature invalidated]). We should also clearly state the allowed input args, e.g. can a list of credentials be passed? Do we expect the credentials in JSON form or as strings? --- `vp/{id}` - roughly same feedback as `/vc/{id}` --- `vp/verify/` - roughly same feedback as `/vc/verify` --- `/users/external/{id}` - how is this endpoint different from the `/did{id}` endpoint? What separates an external user from an internal(?) one? ### Question(s) related to `issuer` endpoint group. What updates / modifications are envisioned (to the request arguments / return types) to support SIOP v2 enabled Wallets? Perhaps this is already supported given the current API? --- `/issuer/createOffer` - It seems like the contents of the credential (i.e. what claims will be included) can / need to be set when creating the request, do we envision use cases where provisioning the claims with data needs to be delayed to a later stage (e..g once the user responds)? - Also, do we envision issuing multiple credentials in one interaction? If yes, the request body would have to be updated. --- `/issuer/status/{id}` - seems reasonable, given an interaction ID, will return the interaction state record. There seems to be some overlap with the `/issuer/previewOffer` endpoint (e.g. `claims`, `credentialType`), what is the core distinction between these endpoints? --- `/issuer/previewOffer` - simillar to the endpoint above. Is the entire request body required as an argument (it seems like the `transactionId`, and perhasps some entries from the `config` object mandatory)(?). Returned info includes: 1. VC Formats, types 2. Populated claims to be included in the issued cred 3. Issuer label and key type Which overlaps quite a bit with the `/issuer/status/{id}` return values. ### Question(s) related to `verifier` endpoint group. What updates / modifications are envisioned (to the request arguments / return types) to support SIOP v2 enabled Wallets? Perhaps this is already supported given the current API? --- `/verifier/requestVerifiableCredential` - Should we be able to select which verifier identity should be used to create the request (like we do with the issuance endpoint)? --- `/verifier/getVerifiableCredential` - seems reasonable, current understanding is that this call will return the current interaction state, analogous to `/issuer/status/{id}`.