search

TBD54566975 / tbdex

56 stars 25 forks source link

Validate RFQ's VC subject DID is equal to RFQ's metadata.from DID #184

Closed KendallWeihe closed 8 months ago

KendallWeihe commented 10 months ago

(I originally posted this here, but that's the wrong repo as this is a protocol matter)

Originally brought up here https://discord.com/channels/937858703112155166/1169748991982968963

In natural language, we need to assert that the RFQ's VC is issued to the same DID from which the RFQ is from.

There is a broader discussion to be had around whether or not delegation ought to be supported, in which, an RFQ could be submitted on behalf of another entity. In which case, the RFQ's metadata.from DID would not be equal to the claims' (the "VC's") DID. But, for the time being, I think it's safe to assume we should support validating an RFQ lines-up-with the given VC.

Breaking down the technicals...

  1. Issuer issues a VC, wherein the VC contains a sub field within the payload which is the DID of the given subject (hereafter referred to as "Alice")
  2. Alice then creates an RFQ message, which contains both their did (in metadata.from) and the newly minted VC (in claims)
  3. Alice sends the message to the PFI
  4. The PFI then verifies VC

But nowhere within verifying the VC, is the PFI also asserting that the given VC is associated with the encompassing RFQ.

There's a fair point to be raised of what is the value of this? Are any additional security assurances guaranteed?

Well, you could imagine someone who can't pass a VC issuance, who gains access to a VC of someone who can, and then they use that VC to bypass their failure to acquire a legitimate VC. But then of course, they could just spoof the metadata.from DID without problem. However, since they don't have the private keys, they cannot spoof the signature. So yes, we do get additional security assurances here.

mistermoe commented 8 months ago

i believe this has been addressed in both js and kt!