HTTP endpoint to import trusted data

Requirements

• The endpoint will accept data formatted as JSON-LD Verifiable Credential or Presentation.
• It must validate the schema, JSON-LD contexts and proofs
• If data is valid, it will be inserted into the cache

Questions to discuss with @valerii.kalashnikov and @SchulzeStTSI

Q1: Should the complete VC/VP with the proof be inserted in the cache, or just the real data from the credentialSubject field?

Q2: Where the public keys of OCM/TSA will be exposed, so that they can be used to validate the proofs on the incoming VC/VP?

Q3: What cache keys should be used when inserting the data in Cache?

changed milestone to %Sprint 10

added DevInProgress label

assigned to @lyuben.penkovski

changed the description

Q1:

Am I right that currently we are keeping the real data in the cache and while exporting functionality we just return VP/VC as an output? In such case we need to put only credentialsSubject into the cache while importing

Q2:

@lyuben.penkovski do you mean that what protocol for resolving DID should be used?

I mean the real address/location where keys will be exposed. I think I'll have to make such temporary endpoint (for testing purposes), because otherwise I cannot test if the functionality is working.

For example, if I want to test the import, I have to give a VP with a proof which mentions where is the public key for verification. In order for the import endpoint to work, it would have to verify the proof and fetch the public key - but currently we don't have a place from where to fetch the public key.

That's what I meant by this question - do we know where these keys will be exposed as address/location.

The public key we can obtain from DID. Can we maybe make this DID (aka "did":"did:key:12345") one of the arguments for the request input data? And then resolve it under the hood and fetch the public key from the DID document?

The "did:key:12345" is already included in the VC/VP, no problem with that - in fact, it is a required part of the proof in VC/VP and is set in the verificationMethod:

{
  ...
  "proof": {
    "created": "2022-06-15T07:13:50.495652716Z",
    "proofPurpose": "assertionMethod",
    "proofValue": "dmF1bHQ6djE6TUVRQ0lGWE0wVnJZVElqSFR2YWtjQm4yOU42S2s4aUpHaWtxYzkzMVJ5YmVWYUdVQWlBZm0rOHRXQXAxVnZWTk44TGpyYWIvY3d1YUpBbTV4dUhucjQvNHNPZ3diZz09",
    "type": "EcdsaSecp256k1Signature2019",
    "verificationMethod": "did:key:12345"
  }
}

The problem is that these are not the real public key bytes, but just key name/alias. From there, the import endpoint must fetch the real public key bytes from somewhere so that it can verify the signature in the proof.

The question is - where is this somewhere for the members of GaiaX - OCM endpoint, Organization Web Site, or somewhere else.

For the moment my plan is to create such temporary test endpoint that returns a predefined static public key to test the importing of data. But this is not the proper solution IMO.

Q3:

I would propose using the same evaluationID idea - but while importing just generate new UUID value and set it as evaluationID

Ok, sounds good, just one question here.

If we do it like this, how would someone inside the organization know the evaluationID so that he can later retrieve the data? I mean, some unknown external data comes in with a random key ID and is placed in Cache.

How will someone ever take the data, when they don't know the key (evaluationID)?

After importing the data, we can return evaluationID in the response for further usage. Or do you mean something different?

Yes we can, if this is OK and is what's needed, then it should be fine.

At least I can't see any other methods to solve it. If the client is interested in interacting with API, he will be able to save it the memory database for further extractions

removed DevInProgress label

added DevInProgress InPreparation labels

mentioned in merge request !6 (merged)

mentioned in commit 10969fa7

closed with merge request !6 (merged)