There is a problem when calling the presentation interface

[shanfeng9001]

We plan to use https://github.com/GLEIF-IT/vlei-verifier to implement credential verification. However, we have encountered some issues and would like to seek advice on how to resolve them.
When we use the following command:
curl -v -X PUT "http://127.0.0.1:7676/presentations/EDgNZjB-XREf6KXRnYFR1mztbY5MjIqiPyVuT8Tw4DNR" -H "Content-Type: application/json+cesr" -d @ecr.json
an error occurred.

The SAID and the ecr credential file (ecr.json) were generated using the following commands:

SAID=$(kli vc list --name qvi --alias qvi --issued --said --schema EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw)
kli vc export --name person --alias person --passcode DoB26Fj4x9LboAFWJra17O --said $SAID > ecr.json
These commands were referenced from issue-xbrl-attestation.sh.

We would like to understand the reason for the error. Is it due to incorrect SAID and ECR credential retrieval methods, or could there be another issue?

thanks!

[shanfeng9001]

According to the description in the document:

_For an AID to be registered as a valid report submitter it must use the /presentations/{said} API to present a valid vLEI ECR credential in the body of a PUT request with a content type of application/json+cesr. The said in the URL is the SAID of the credential being presented in the body. This API will return a 202 response code to indicate that the credential presentation has been accepted but with no indication of the validity of the presentation.

I have three questions:
Who is the value of SAID and how can it be obtained?
2. What command can be used to obtain the ECR credential required here? Can the credential of ECR application be exported through kli vc export method?
3. Is it okay if it's not an ECR credential? For example, OOR credential

[2byrds]

Hi @shanfeng9001 thank you for the details. Did the export include all of the elements needed for cryptographic verification, or just the credential? Likely you aren't exporting the 'full chain' of cryptographic data. Put another way, the verifier cannot verify the credential json+cesr alone. It needs the full chain and related identifier json+cesr.

[2byrds]

@shanfeng9001 regarding your other questions.

• The SAID should be the credential SAID.
• The verifier presentation can cryptographically verify any credential
• However, currently the verifier has some specific authorization logic, for the customer use case we're actively working on. For now, it can only authorize ECR creds with the 'EBA Data Submitter' role.
  • There is a PR that will be merged next week that will allow you to configure a list of authorized roles for the ECR.
  • We have been working to make it more and more generic. It WILL be able to authorize OOR creds in early 2025.

[shanfeng9001]

Thank you very much for your reply. It's really helpful to us.

Now, we still have many questions:

1. Which type of target users is the vlei-verifier project intended for? What are the specific application scenarios? Is it only applicable to EBA data submitters?

2. The verification path we are currently following is as follows:
   Firstly, we have completed the creation and document signing of certificates such as ECR and OOR through keripy/script/../issue-xbrl-attestation.sh, and we hope to verify the identity of the signatories. The credentials of the signatories may be OOR or ECR. Then we noticed the vlei-verifier project, and thus, questions arose.
   Secondly, what recommended implementation methods do you have for achieving the identity authentication of the signatories? Is our requirement suitable for using this vlei-verifier project?

3. In the /presentation/{SAID} API, is {SAID} the SAID of the ECR credential? Can it be the following command? If not, how should I obtain it?
   SAID=$(kli vc list --name qvi --alias qvi --issued --said --schema EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw)

4. How can the credentials be obtained? Is this credential currently only the ECR credential? Is it exported through kli vc export? If not, how to obtain or export the ECR credential?
   kli vc export --name person --alias person --passcode DoB26Fj4x9LboAFWJra17O --said $SAID > ecr.json

thanks!

[2byrds]

@shanfeng9001 I have responded inline, below:

1. Which type of target users is the vlei-verifier project intended for? What are the specific application scenarios? Is it only applicable to EBA data submitters?
   It is evolving to be a generic vlei verification service for use by anyone needing to verify a vlei credential, signature, etc.
   It will be generic/configurable enough for most vLEI use cases in Q1 2025.
   However, we are happy to prioritize EBA and then your requirements as we evolve the service over the next months. Real grounded use cases are most effective for helping us set milestones that will serve the most pressing use cases.

2. The verification path we are currently following is as follows:
   Firstly, we have completed the creation and document signing of certificates such as ECR and OOR through keripy/script/../issue-xbrl-attestation.sh, and we hope to verify the identity of the signatories. The credentials of the signatories may be OOR or ECR. Then we noticed the vlei-verifier project, and thus, questions arose.
   That's is great information. We will use our own OOR test data first, but then will be happy to repeat the same series of operations to further validate the OOR verification.

Secondly, what recommended implementation methods do you have for achieving the identity authentication of the signatories? Is our requirement suitable for using this vlei-verifier project?
Once the verifier is able to authorize, via the OOR credential (or ECR with a different role) then the verifier will retain the Identifier information so that it can authenticate signatures. As part of the evolution towards general vlei identifier authentication, we could make it so you don't have to present a credential chain in order to authenticate. Instead you will be able to load a set of OOBIs for an identifier, and then the verifier will be able verify signatures for those identifiers.

3. In the /presentation/{SAID} API, is {SAID} the SAID of the ECR credential? Can it be the following command? If not, how should I obtain it?
   SAID=$(kli vc list --name qvi --alias qvi --issued --said --schema EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw)
   In the EBA case the customers are using KERIA which provides the full chain. I will need to revisit the keripy commandline to answer what the proper set of flags are.

4. How can the credentials be obtained? Is this credential currently only the ECR credential? Is it exported through kli vc export? If not, how to obtain or export the ECR credential?
   kli vc export --name person --alias person --passcode DoB26Fj4x9LboAFWJra17O --said $SAID > ecr.json
   Same as my answer for 3. I'll visit the command line soon and let you know.

[shanfeng9001]

thanks !
When researching the vLEI-verifier project, our primary goal is to ensure that the vLEI-verifier runs smoothly and that the /presentations/{said} and /authorizations/{aid} endpoints are accessible and return the expected responses. Currently, we are unsure how and where to correctly obtain the {said} and credential information.

We look forward to your further feedback. Thank you very much!

[2byrds]

@shanfeng9001 that sounds good. however, if you will also be using signify/keria then you can refer to the reg-pilot repos which has tests, test-data, a test webapp, etc. that will help you see the end-to-end flow

[shanfeng9001]

@shanfeng9001 I have responded inline, below:

1. Which type of target users is the vlei-verifier project intended for? What are the specific application scenarios? Is it only applicable to EBA data submitters?
   It is evolving to be a generic vlei verification service for use by anyone needing to verify a vlei credential, signature, etc.
   It will be generic/configurable enough for most vLEI use cases in Q1 2025.
   However, we are happy to prioritize EBA and then your requirements as we evolve the service over the next months. Real grounded use cases are most effective for helping us set milestones that will serve the most pressing use cases.

2. The verification path we are currently following is as follows:
   Firstly, we have completed the creation and document signing of certificates such as ECR and OOR through keripy/script/../issue-xbrl-attestation.sh, and we hope to verify the identity of the signatories. The credentials of the signatories may be OOR or ECR. Then we noticed the vlei-verifier project, and thus, questions arose.
   That's is great information. We will use our own OOR test data first, but then will be happy to repeat the same series of operations to further validate the OOR verification.

Secondly, what recommended implementation methods do you have for achieving the identity authentication of the signatories? Is our requirement suitable for using this vlei-verifier project?
Once the verifier is able to authorize, via the OOR credential (or ECR with a different role) then the verifier will retain the Identifier information so that it can authenticate signatures. As part of the evolution towards general vlei identifier authentication, we could make it so you don't have to present a credential chain in order to authenticate. Instead you will be able to load a set of OOBIs for an identifier, and then the verifier will be able verify signatures for those identifiers.

3. In the /presentation/{SAID} API, is {SAID} the SAID of the ECR credential? Can it be the following command? If not, how should I obtain it?
   SAID=$(kli vc list --name qvi --alias qvi --issued --said --schema EEy9PkikFcANV1l7EHukCeXqrzT1hNZjGlUk7wuMO5jw)
   In the EBA case the customers are using KERIA which provides the full chain. I will need to revisit the keripy commandline to answer what the proper set of flags are.

4. How can the credentials be obtained? Is this credential currently only the ECR credential? Is it exported through kli vc export? If not, how to obtain or export the ECR credential?
   kli vc export --name person --alias person --passcode DoB26Fj4x9LboAFWJra17O --said $SAID > ecr.json
   Same as my answer for 3. I'll visit the command line soon and let you know.

Is there any further conclusion regarding 3 and 4? thank you very much !