Replies: 5 comments 3 replies
-
Nice work just writing up and summarising the actions to be taken. For action 1b: For action 1c: For action 1d: |
Beta Was this translation helpful? Give feedback.
-
some thoughts on backward compatibility on decentralised renderer side Open-Attestation/tutorial-renderer#1 |
Beta Was this translation helpful? Give feedback.
-
Action 1a: Utilise credentialSchema instead of version I'm not sure this fits with the purpose of the credentialSchema - the primary aim there is to allow issuers to include a schema defining the syntax of the claims represented in the credentialSubject. I think there are two distinct processes being merged here:
for the purposes of action 1a, I think this could easily be achieved by just adding the type Action 1b: Consolidate all issuer-related information into issuer field there are two objects defined in the example OAv4 issuer object example above that map to concepts defined in the VC data model and are expected to be keys in the root of the credential. OA "revocation" -> VCDM "credentialStatus" (see https://www.w3.org/TR/vc-data-model/#status) the latter is of course just a reserved word in the draft v2 spec, but you can see where they are headed... I think rather than including "revocation" and "renderer" nested under the "issuer" object, the approach more in line with the VCDM would be to publish both these mechanisms as credential status and render method specs and use the standard structure to reference them. |
Beta Was this translation helpful? Give feedback.
-
For those following this thread, OpenAttestation v4 (beta) has been released to incorporate the changes listed here (i.e. aligning with the W3C VC Data Model) |
Beta Was this translation helpful? Give feedback.
-
Closing this thread in favour of #309 to consolidate any last feedback/suggestions before we finalise the release of OpenAttestation OA v4.0 |
Beta Was this translation helpful? Give feedback.
-
Context
There have been some concerns (e.g. #233, #234, etc.) that the Verifiable Credentials (VCs) generated by the OpenAttestation framework may not be interoperable with other W3C VC wallets/platforms in the wild.
To resolve these concerns, we have established 3 action items laid out in this document:
OpenAttestationMerkleProofSignature2018
onto W3C and IETFObjective
This document aims to document proposed changes and facilitate collaboration from the community to achieve W3C interoperability.
To facilitate ease of communication, we will use the following alias:
OA v3
: The current state of OpenAttestation v3OA v4
: The proposed changes laid out in this documentAction 1: Aligning with the W3C VC Data Model
Action 1a: Omit the use of
and leaveversion
credentialSchema
emptyIn OA v3, a wrapped (or signed/issued) VC may look something like this:
However, the
version
field that is currently used in OA v3 is not part of the VC base context. For the OA framework to easily identify the version of the VC, OA v4 will rely on the expanded URI where@type
containshttps://schema.openattestation.com/4.0/credentials#OpenAttestationCredential
.Example of a OA v4 VC in an expanded document form:
Action 1a Conclusion:
fieldversion
credentialSchema
field empty for issuers to insert at their discretion to describe the schema ofcredentialSubject
Action 1b: Consolidate all issuer-related information into
issuer
fieldIn OA v3, a DID-signed VC may look something like this:
The current verification process in OA v3 only verifies against the
proof.key
field andopenAttestationMetadata.proof.value
field. The current OA v3 verification process does not involve any part of theissuer
field which may cause irregularities with external verifiers.In contrast, the W3C data model specifications states that the
issuer
field should be utilised:In OA v4, issuance will be described in their respective fields:
issuer
- Issuer and identity related informationcredentialStatus
- Revocation status (if any)renderMethod
- Rendering instructions (if any)Action 1b Conclusion:
issuer.id
field instead of theopenAttestationMetadata.proof.value
field.fieldopenAttestationMetadata
issuer
,credentialStatus
andrenderMethod
Action 1c: Supporting other DID methods (e.g.
did:web:xxx
, etc.)In the current oa-verify implementation:
did:web:example.com
EcdsaSecp256k1RecoveryMethod2020
signature method is supporteddid:web:xxx
resolved to the same DID Document of their existingdid:ethr:xxx
, verification may continue to work (though some code changes may be required)For example, here's the DID Document of
did:ethr:0x1245e5B64D785b25057f7438F715f4aA5D965733
:Action 1c Conclusion
EcdsaSecp256k1RecoveryMethod2020
)ethers.js
for end-users to utilise)Action 1d:
issuer.identityProof
will be redundant if other DID methodsWith Action 1c implemented, the
DNS-DID
identity proof that OA currently uses (i.e. creating a DNS TXT record to declare ownership of the domain) is no longer necessary if adid:web:xxx
is used for issuance since the nature of resolving this DID is already establishing a link with the domain.Action 1d Conclusion
identityProof
should be optional if adid:web:xxx
(or any other similar domain-backed DID) is usedAction 1e: Reduce/consolidate OpenAttestation specific @contexts
In OA v4, a single JSON-LD context definition is used to give semantic meaning to all OpenAttestation specific fields and can be declared in this way:
The proposed OA v4 JSON-LD context definition (
https://schemata.openattestation.com/com/openattestation/4.0/alpha-context.json
):Action 1e Conclusion
VerifiableCredential
andOpenAttestationCredential
credentialSubject
) will need to be defined/provided by each issuerAction 2: Test against the VC API test suite
VC API Test Suite: https://github.com/w3c/vc-data-model-2.0-test-suite
Findings:
Action 3: Publishing OAMerkleProofSignature2018 specification
W3C draft (source): https://open-attestation.github.io/OAMerkleProofSignature2018/
IETF draft:⚠️ [Work in progress]
Beta Was this translation helpful? Give feedback.
All reactions