Verification of DID-signed OAv3 docs and openAttestationDidIdentityProof

[morgatron]

In thinking about how OA might be used to verify generic W3C VCs, I'm trying to be sure that I fully understand OA's verification process. It seems to be a little awkward for DID-signed docs, and I think this needs to be understood to tackle generic w3c VCs.

First let me briefly explain how I think OA's verification works:

OA has a neat feature of different "verification types": (DOCUMENT_INTEGRITY, DOCUMENT_STATUS, ISSUER_IDENTITY).
Checking all these ensures that (copied from the README of oa-verify):

1. The document has NOT been tampered, AND
2. The document has been issued, AND
3. The document has NOT been revoked, AND  
4. The issuer identity is valid.        

Looking at oa-verify code, it seems to me that 1. maps to DOCUMENT_INTEGRITY,, 2. and 3. to DOCUMENT_STATUS, and 4. maps to ISSUER_IDENTITY.

For document store issued OA docs, this all makes perfect sense: DOCUMENT_INTEGRITY means the hash of the doc is accurate, DOCUMENT_STATUS means it's been issued to the store by the included ethereum ID, and ISSUER_IDENTITY means that the issuer's website claims to control that ethereum ID. There are two IDs here: the ethereum ID, and the issuer's domain.

However for did-signed docs, the match seems awkward. This is because there's really only one ID: the "did" of the issuer

For did-signed docs, there are currently has two seperate signature checks:

• openAttestationDidSignedDocumentStatus checks the signature and for revocation and validates DOCUMENT_STATUS
• openAttestationDidIdentityProof does the signature check again and validates ISSUER_IDENTITY

In the tests, both checks are included to make did-signed docs verify.

The question:

If I'm correct with the above, is there a reason for having openAttestationDidIdentityProof apart from helping tests pass?

The only use case I can see is to allow a verifier to check for ISSUER_IDENTIY in general but ignore it for did-signed documents. But my feeling is that if a verifier cares about ISSUER_IDENTITY at all, they shouldn't be verifying did-signed documents unless they're signed by a known, whitelisted ethereum ID. And in that case shouldn't they write they're own openAttestationIdentityProof check that matches the issuer against their whitelist?

In any case, if anyone is able to confirm that I'm on the right track with the above, I would like to raise an issue and eventually raise a PR for applying these to generic W3C VCs,

[osslgtm]

The current workflow for did documents are available here:
https://www.openattestation.com/docs/developer-section/libraries/verification/verification-flow with links to the code

List of verification methods and their purpose:
https://www.openattestation.com/docs/developer-section/libraries/remote-files/open-attestation-verify#verification-method

Default verification methods (openAttestationVerifiers):

oa-verify/src/index.ts

Line 19 in fd5d5f0

const openAttestationVerifiers = [

I'm not exactly sure what the purpose of openAttestationDidIdentityProof is, but I suspect that it's used as an option for an alternative workflow, like if you have a custom workflow that skips some of the verification steps.

openAttestationDidIdentityProof is not included in the default workflow, as in openAttestationVerifiers

( I'll update the answer when i've got a more comprehensive picture of the alternative workflow )

[morgatron]

Thanks for the reply! Looking forward to the update- let me know if I should clarify my question at all.

I'll just note that while those quick-start docs are very nice, one of the reasons I decided to ask this question was because there's some small inconsistencies in the various documentation.

I think the flow-chart in particular is not right. For did-signed docs I think it's this:

flowchart TB
    subgraph A[OpenAttestationHash]
        direction TB
        A1[start] --> A2
        A2[check schema] --> A3[verify hash]
        
    end
    subgraph B[DidSignedDocumentStatus]
        direction TB
        B1[Check signature] -->B2[check revocation status]
    end
    subgraph C[DidIdentityProof]
        direction TB
        C1[Check signature]
    end
    A --> B -->C

As for the methods link appears to reflect what the code does, with one innacuracy: quibble that OpenAttestationDidSignedDocumentStatus also checks revocation status (via OCSP), not just for signature validity.

Just to clarify my main point: I think DID-signed docs simply don't have an identity proof. This means that in the usual workflow, where a user requires all documents pass DOCUMENT_INTEGRITY, DOCUMENT_STATS, and ISSUER_IDENTITY, a did-signed doc can never pass... unless ISSUER_IDENTITY means something different in this case.

There are a couple of places I can think of where "ISSUER_IDENTITY" would make sense for a did-signed doc, though

1. If the particular did:eth address is known to the verifier (it's on a whitelist)
2. If the issuer is "did:dns" or "did:web" (since these are both linking keys to addresses as OA does)

Thanks for taking the time to answer.

[osslgtm]

The actual workflow checks for signature on both openAttestationHash and DidSignedDocumentStatus.

So i decided to omit the same process on DidSignedDocumentStatus to avoid confusion.

There's a full flowchart on the functions that are called during verification when i was working on this:
2af6e29
but i think a complete flowchart will be too confusing for end users to figure out.

I think i'll either remove the processes in the verification stage, or remove it entirely.