@bsv/vsc 0.2.0-beta.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +58 -0
- package/README.md +107 -0
- package/artifacts/context-0.1.0.jsonld +127 -0
- package/artifacts/disclosure-0.1.0.schema.json +526 -0
- package/artifacts/epcis/NOTICE.md +11 -0
- package/artifacts/epcis/epcis-context-2.0.1.jsonld +593 -0
- package/artifacts/epcis/epcis-json-schema-2.0.1.json +2352 -0
- package/artifacts/epcis/query-schema-2.0.1.json +968 -0
- package/artifacts/external/NOTICE.md +3 -0
- package/artifacts/external/dpp-external-passport-1.context.jsonld +8 -0
- package/artifacts/external/dpp-external-passport-1.schema.json +158 -0
- package/artifacts/profile-0.1.0.json +100 -0
- package/artifacts/seal-0.1.0.schema.json +535 -0
- package/artifacts/w3c/NOTICE.md +3 -0
- package/artifacts/w3c/credentials-v2.jsonld +340 -0
- package/dist/context.d.ts +9 -0
- package/dist/context.d.ts.map +1 -0
- package/dist/context.js +50 -0
- package/dist/context.js.map +1 -0
- package/dist/crypto.d.ts +50 -0
- package/dist/crypto.d.ts.map +1 -0
- package/dist/crypto.js +141 -0
- package/dist/crypto.js.map +1 -0
- package/dist/did-web.d.ts +9 -0
- package/dist/did-web.d.ts.map +1 -0
- package/dist/did-web.js +66 -0
- package/dist/did-web.js.map +1 -0
- package/dist/epcis-source.d.ts +251 -0
- package/dist/epcis-source.d.ts.map +1 -0
- package/dist/epcis-source.js +573 -0
- package/dist/epcis-source.js.map +1 -0
- package/dist/epcis.d.ts +51 -0
- package/dist/epcis.d.ts.map +1 -0
- package/dist/epcis.js +171 -0
- package/dist/epcis.js.map +1 -0
- package/dist/exchange.d.ts +175 -0
- package/dist/exchange.d.ts.map +1 -0
- package/dist/exchange.js +491 -0
- package/dist/exchange.js.map +1 -0
- package/dist/index.d.ts +10 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +10 -0
- package/dist/index.js.map +1 -0
- package/dist/jcs.d.ts +25 -0
- package/dist/jcs.d.ts.map +1 -0
- package/dist/jcs.js +67 -0
- package/dist/jcs.js.map +1 -0
- package/dist/schema.d.ts +414 -0
- package/dist/schema.d.ts.map +1 -0
- package/dist/schema.js +537 -0
- package/dist/schema.js.map +1 -0
- package/dist/types.d.ts +159 -0
- package/dist/types.d.ts.map +1 -0
- package/dist/types.js +2 -0
- package/dist/types.js.map +1 -0
- package/dist/validation.d.ts +22 -0
- package/dist/validation.d.ts.map +1 -0
- package/dist/validation.js +147 -0
- package/dist/validation.js.map +1 -0
- package/dist/verification.d.ts +10 -0
- package/dist/verification.d.ts.map +1 -0
- package/dist/verification.js +350 -0
- package/dist/verification.js.map +1 -0
- package/package.json +68 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
Open BSV License Version 6 – granted by BSV Association, Alpenstrasse 15, 6300
|
|
2
|
+
Zug, Switzerland (CHE-427.008.338) ("Licensor"), to you as a user (henceforth
|
|
3
|
+
"You", "User" or "Licensee").
|
|
4
|
+
|
|
5
|
+
For the purposes of this license, the definitions below have the following
|
|
6
|
+
meanings:
|
|
7
|
+
|
|
8
|
+
"Bitcoin Protocol" means the protocol implementation, cryptographic rules,
|
|
9
|
+
network protocols, and consensus mechanisms in the Bitcoin White Paper as
|
|
10
|
+
described here https://protocol.bsvblockchain.org.
|
|
11
|
+
|
|
12
|
+
"Bitcoin White Paper" means the paper entitled 'Bitcoin: A Peer-to-Peer
|
|
13
|
+
Electronic Cash System' published by 'Satoshi Nakamoto' in October 2008.
|
|
14
|
+
|
|
15
|
+
"BSV Blockchain" means:
|
|
16
|
+
|
|
17
|
+
(a) the Bitcoin blockchain containing block height #556767 with the hash
|
|
18
|
+
"000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b" and
|
|
19
|
+
that contains the longest honest persistent chain of blocks which has been
|
|
20
|
+
produced in a manner which is consistent with the rules set forth in the
|
|
21
|
+
Network Access Rules; and
|
|
22
|
+
(b) the test blockchains that contain the longest honest persistent chains of
|
|
23
|
+
blocks which has been produced in a manner which is consistent with the
|
|
24
|
+
rules set forth in the Network Access Rules.
|
|
25
|
+
|
|
26
|
+
"Network Access Rules" or "Rules" means the set of rules regulating the
|
|
27
|
+
relationship between BSV Association and the nodes on BSV based on the Bitcoin
|
|
28
|
+
Protocol rules and those set out in the Bitcoin White Paper, and available here
|
|
29
|
+
https://bsvblockchain.org/network-access-rules.
|
|
30
|
+
|
|
31
|
+
"Software" means the software the subject of this license, including any/all
|
|
32
|
+
intellectual property rights therein and associated documentation files.
|
|
33
|
+
|
|
34
|
+
BSV Association grants permission, free of charge and on a non-exclusive basis
|
|
35
|
+
to any person obtaining a copy of the Software to deal in the Software, including
|
|
36
|
+
without limitation the rights to use, copy, modify, merge, publish, distribute,
|
|
37
|
+
sublicense, and/or sell copies of the Software, and to permit persons to whom the
|
|
38
|
+
Software is furnished to do so, subject to and conditioned upon the following
|
|
39
|
+
conditions:
|
|
40
|
+
|
|
41
|
+
1 - The text "© BSV Association", and this license shall be included in all
|
|
42
|
+
copies or substantial portions of the Software.
|
|
43
|
+
|
|
44
|
+
2 - The Software, and any software that is derived from the Software or parts
|
|
45
|
+
thereof, may only be used exclusively on the BSV Blockchain.
|
|
46
|
+
|
|
47
|
+
For the avoidance of doubt, this license is granted subject to and conditioned
|
|
48
|
+
upon your compliance with these terms only and is limited to uses on the BSV
|
|
49
|
+
Blockchain. Any exercise of rights not compliant with these terms including
|
|
50
|
+
use not for the BSV Blockchain is deemed outside the scope of the license.
|
|
51
|
+
|
|
52
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
53
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES REGARDING ENTITLEMENT,
|
|
54
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
|
|
55
|
+
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS THEREOF BE LIABLE FOR ANY CLAIM,
|
|
56
|
+
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
|
|
57
|
+
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
58
|
+
DEALINGS IN THE SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# VSC draft compatibility profile
|
|
2
|
+
|
|
3
|
+
**Experimental prerelease:** For implementation and interoperability testing. APIs may change significantly before a stable release. Pin exact package versions and retain your lockfile. This package is not declared production-ready. Package versions are separate from the specification, wire-format and frozen profile versions they implement.
|
|
4
|
+
|
|
5
|
+
## Install
|
|
6
|
+
|
|
7
|
+
This is a pre-1.0 candidate. After publication, install the selected version from npm:
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
npm install --save-exact @bsv/vsc@0.2.0-beta.1
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The runtime and its exchange and EPCIS subpaths require Node >=22 and ECMAScript modules. Browser runtime use is unsupported; artefact exports are plain data. No repository checkout or package build is needed after installation.
|
|
14
|
+
|
|
15
|
+
`@bsv/vsc` implements the local `vsc-draft-compat/0.1.0` profile against the VSC Community Group draft at revision `c279de3debcd6eab94a77034584d1750f5d65e6a`. It has no BSV runtime dependency. It does not claim W3C certification, completion of upstream conformance tests, or regulatory compliance.
|
|
16
|
+
|
|
17
|
+
The package includes strict secured SEAL parsing, an owned JSON-LD context and schema, Ed25519Signature2020 issuance and verification, BBS issuance and request-bound selective disclosure, authenticated status and issuer-authority checks, and custody DAG and correction evaluation. It preserves all five EPCIS event types in signed round-trip extensions. Unsupported or insufficient mappings fail instead of inventing event information.
|
|
18
|
+
|
|
19
|
+
## Issuance and verification
|
|
20
|
+
|
|
21
|
+
```ts
|
|
22
|
+
import {
|
|
23
|
+
createDocumentLoader, issueSealEd25519, verifySeal, parseSealBytes,
|
|
24
|
+
} from '@bsv/vsc';
|
|
25
|
+
|
|
26
|
+
// Documents and trust anchors come from the operator's configured evidence policy.
|
|
27
|
+
// Do not accept a credential's own assertion that its issuer is trusted.
|
|
28
|
+
const documentLoader = createDocumentLoader(documents);
|
|
29
|
+
const credential = await issueSealEd25519({ credential: unsignedSeal, key, documentLoader });
|
|
30
|
+
const result = await verifySeal({
|
|
31
|
+
credential,
|
|
32
|
+
documentLoader,
|
|
33
|
+
evaluationTime: new Date().toISOString(),
|
|
34
|
+
statusPolicy: {
|
|
35
|
+
id: 'urn:example:status-policy:1',
|
|
36
|
+
maxAgeMs: 86_400_000,
|
|
37
|
+
resolve: async url => {
|
|
38
|
+
const evidence = statusCredentials.get(url);
|
|
39
|
+
if (!evidence) throw new Error('Status evidence unavailable');
|
|
40
|
+
return evidence;
|
|
41
|
+
},
|
|
42
|
+
},
|
|
43
|
+
authorityPolicy: {
|
|
44
|
+
id: 'urn:example:issuer-policy:1',
|
|
45
|
+
required: true,
|
|
46
|
+
trustAnchors: trustedAuthorityDids,
|
|
47
|
+
resolve: async issuer => authorisationsByIssuer.get(issuer) ?? [],
|
|
48
|
+
},
|
|
49
|
+
resolveSeal: async id => historicalCredentials.get(id),
|
|
50
|
+
corrections: discoveredCorrections,
|
|
51
|
+
});
|
|
52
|
+
|
|
53
|
+
// Retain the bytes supplied to parseSealBytes separately for exact-byte anchoring.
|
|
54
|
+
const received = parseSealBytes(originalBytes);
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Resolvers return signed evidence, never a Boolean saying that verification passed. A status resolver must return a signed `BitstringStatusListCredential`. Its identifier, issuer authority, proof, status purpose, validity, signed freshness and bit index are checked before its contents are used. Decompression is bounded. Third-party list issuers require an explicit grant in `statusPolicy.delegatedListIssuers`. Configure at most 24 hours for pharmaceutical and food contexts; the generic upper bound is seven days.
|
|
58
|
+
|
|
59
|
+
Required issuer authority uses signed `VscEventAuthorisation` credentials. Their issuer must be an operator-configured trust anchor; `credentialSubject.id` identifies the authorised issuer, `permittedEventTypes` is required, and optional `permittedProductSchemes` and `permittedJurisdictions` restrict the grant. Grant proofs, validity and status are verified. An explicit `{id, required: false, reason}` policy records that external authority is not required by this verifier, and returns an `authority_not_required` warning. Missing policy remains indeterminate.
|
|
60
|
+
|
|
61
|
+
`createDocumentLoader` supplies pinned standard and local contexts. The optional `createDidWebResolver({allowedOrigins})` resolves permitted HTTPS origins, refusing redirects and bounding time and size. Other DID methods can be supplied through the document-loader interface. The loader must return the requested issuer DID document, its authorised assertion methods and associated public key material. Resolving a key does not by itself authorise that key to sign for an issuer.
|
|
62
|
+
|
|
63
|
+
## Proofs and selective disclosure
|
|
64
|
+
|
|
65
|
+
`issueSealEd25519` uses the maintained Ed25519Signature2020 suite with JSON-LD/RDF canonicalisation. It does not substitute an Ed25519 JWS or a signature over JSON text. `issueSealBbs` uses the maintained `bbs-2023` cryptosuite. These use different keys and produce independently secured representations; a key's DID relationship must authorise its actual proof purpose.
|
|
66
|
+
|
|
67
|
+
`deriveSealPresentation` produces a genuine BBS derived credential. Its `binding` contains a request identifier, unpredictable challenge, verifier DID, holder DID and expiry. `verifySealPresentation` checks that binding and the required disclosed fields. The cryptographic presentation header prevents moving the result to a different request or verifier. It does not prove possession of a holder authentication key; applications needing holder authentication must establish that separately.
|
|
68
|
+
|
|
69
|
+
The disclosure helper is a cryptographic primitive, not an access-control endpoint. The caller must authorise every optional JSON pointer before requesting disclosure. The package deliberately does not implement the draft's entire HTTPS presentation protocol or treat a caller-supplied authorisation level as a grant.
|
|
70
|
+
|
|
71
|
+
This profile always discloses the credential subject, including mirrored predecessor references. Optional custody fields, location details and domain extensions can be withheld. Empty/null RDF values do not produce statements; the original-record `correctionOf: null` marker is restored after derivation. Non-null correction references are mandatory signed disclosures. A disclosed credential is verified for its revealed claims and request binding, not mistaken for the complete originally anchored byte representation.
|
|
72
|
+
|
|
73
|
+
## Custody and corrections
|
|
74
|
+
|
|
75
|
+
Graph verification uses backward parent references, path-local cycle detection and a completed-node cache. Valid diamond graphs are permitted. Default limits are depth 64, 1,024 visited credentials, 256 parents and a 30-second graph resolution deadline. A limit or missing predecessor yields indeterminate verification.
|
|
76
|
+
|
|
77
|
+
Sequence numbers are branch heights: an origin is 1 and a subsequent custody event is one greater than its highest parent. Linear custody preserves the chain and product identifiers. Terminal states cannot re-enter that chain. A new VSC custody identity does not erase the persistent product or passport identity.
|
|
78
|
+
|
|
79
|
+
Fork issuers preallocate child identifiers before signing. Signed forward references are never filled in retrospectively. The package validates declared child membership when following a fork parent; it does not establish the global completeness or latest state of a distributed history.
|
|
80
|
+
|
|
81
|
+
Corrections retain the original credential and use a separate chain identifier with sequence 1. This profile permits exactly one correction parent, its correction target. The effective event data is projected during downstream state validation; the projection is not presented as another signed credential. Competing authorised corrections return a conflict. Cross-issuer corrections require `correctionPolicy.resolve(originalIssuer, delegate)` to supply a signed `VscCorrectionAuthorisation` from the original issuer, with subject `id` matching the delegate, `originalIssuer`, `permittedRecordIds` and `permittedActions: ['correct']`. Proof, validity and status are checked.
|
|
82
|
+
|
|
83
|
+
Results apply to the supplied/discovered evidence, recorded as `evidenceScope: 'provided-evidence'`. They do not establish global freshness, physical truth, legal ownership, or product-to-label binding.
|
|
84
|
+
|
|
85
|
+
## Identifiers and BSV integration
|
|
86
|
+
|
|
87
|
+
A VSC actor DID identifies the asserting actor. A physical product may separately use a UORA-style object DID in `eventVector.what.productIdentifiers`. Accounts, credential subjects, physical objects, controllers, custodians and signing keys are separate roles. No account-to-brand mapping or mandatory co-controller is inferred.
|
|
88
|
+
|
|
89
|
+
`extractSealMetadata` returns credential `id`, issuer, type and product identifier values as `subjects`. The credential subject ID is the attestation ID in this profile. When anchoring a multi-product record, select an explicit signed product identifier; do not silently use the attestation ID as a product ID.
|
|
90
|
+
|
|
91
|
+
BSV tokenisation, wallet funding, token spend authority, transaction inclusion and overlay discovery stay outside this package. A BSV adapter can anchor the exact complete secured credential bytes and report those additional guarantees separately. Reading or verifying a SEAL requires no blockchain access. Physical-object DID addressing and secure physical binding remain separate capabilities from actor identity and cryptographic credential verification.
|
|
92
|
+
|
|
93
|
+
## Artefacts and limits
|
|
94
|
+
|
|
95
|
+
The [manifest](artifacts/profile-0.1.0.json) records source revisions, implementation decisions and unresolved upstream conformance gates. The owned context uses `urn:bsv:vsc:context:0.1.0`; no invented bytes are served under the upstream draft's missing W3C context URL. Share the versioned artefacts through the package. General upstream interoperability without prior context distribution remains an explicit unmet gate.
|
|
96
|
+
|
|
97
|
+
Pharmaceutical/food regulatory profiles, a full presentation HTTP protocol, independent implementation interoperability certification, regulatory rule engines and secure physical binding are not claimed by this package. Its tests exercise actual suites and evidence checks. Direct upstream-suite verification is useful interoperability evidence, but does not count as an independent implementation certification.
|
|
98
|
+
|
|
99
|
+
## EPCIS source exchange
|
|
100
|
+
|
|
101
|
+
`@bsv/vsc/epcis-source` carries the pinned EPCIS 2.0.1 JSON Schema and JSON-LD context (`artifacts/epcis/`, with their digests in `NOTICE.md`) and the helpers of the `epcis-json@1` and `epcis-vsc@1` interoperability profiles (`spec/epcis-interoperability.md` of the standard). `parseEpcisSource` reads exact bytes under the disclosed limits (2 MiB, depth 64, duplicate keys, malformed UTF-8 and inexact numbers refused before anything is retained) and answers with the envelope kind, every event's JSON pointer and identifier, and the context declarations as written; `validateEpcisDocument` validates against the pinned schema and checks claimed GS1 identifiers without mutating, coercing or stripping a field; `epcisEventBodyDigest` is the RFC 8785 digest of an event body without its `recordTime` and `errorDeclaration`, so equivalent formatting yields one digest and a changed body another; `classifyEventArrival` names a repeat `duplicate`, a changed record time or error declaration `new-observation` and a changed body `conflict`; `localEventIdentity` labels an event that carries no identifier; `epcisSourceReference` builds the signed source reference `urn:bsv:dpp:epcis-source:1` a mapped SEAL carries beside the round-trip extension.
|
|
102
|
+
|
|
103
|
+
`mapEpcisEventWithReport` wraps `mapEpcisEvent`, which is unchanged, and answers with one of the four mapping outcomes: `lossless` only when every member of the event is expressed in the SEAL event vector or retained in the round-trip extension with nothing the profile's mapping limits name dropped, `transformed` with the unmapped semantics listed, `unsupported` for an event type, action or disposition the VSC profile does not express, and `insufficient-data` with every missing requirement named. Retention is never a lossless claim, nothing physical is fabricated to satisfy the SEAL, and a valid EPCIS event may remain evidence-only. Publication, idempotency, checkpoints and the pull client belong to the application service.
|
|
104
|
+
|
|
105
|
+
## External credential verification
|
|
106
|
+
|
|
107
|
+
`@bsv/vsc/exchange` is a separate entry point for the `vc-di-ecdsa-rdfc-2019@1` representation of `spec/external-credential-profile.md`: a W3C Verifiable Credentials 2.0 credential secured with a `DataIntegrityProof` under `ecdsa-rdfc-2019` over a P-256 Multikey whose `did:web` issuer lists the key for assertion. `verifyExternalCredential` reports parse, context set, payload schema, proof, issuer binding, subject binding, temporal, status, authority and availability as separate checks; a P-384 key, another cryptosuite, an inline context or a second credential subject is `unsupported`, never a pass and never a silent fail. The proof primitives are the maintained `@digitalbazaar/ecdsa-rdfc-2019-cryptosuite` and `@digitalbazaar/ecdsa-multikey`; no signature or canonicalisation code is written here. The main entry point's `verifySeal` and `verifyCredentialProof` are untouched and keep refusing every context outside the SEAL set. `externalCredentialVerifierFor` adapts the result to the verification report's credential checks, and a reformatted credential whose RDF proof still verifies is reported apart from the exact bytes an anchor commits to, which differ.
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
{
|
|
2
|
+
"@context": {
|
|
3
|
+
"@version": 1.1,
|
|
4
|
+
"@protected": true,
|
|
5
|
+
"VSC-SEAL": "urn:bsv:vsc:term:SEAL",
|
|
6
|
+
"VscEventAuthorisation": "urn:bsv:vsc:term:EventAuthorisation",
|
|
7
|
+
"VscCorrectionAuthorisation": "urn:bsv:vsc:term:CorrectionAuthorisation",
|
|
8
|
+
"issuanceDate": {
|
|
9
|
+
"@id": "https://www.w3.org/2018/credentials#issuanceDate",
|
|
10
|
+
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
|
|
11
|
+
},
|
|
12
|
+
"sealVersion": "urn:bsv:vsc:term:sealVersion",
|
|
13
|
+
"sealTimestamp": "urn:bsv:vsc:term:sealTimestamp",
|
|
14
|
+
"eventVector": "urn:bsv:vsc:term:eventVector",
|
|
15
|
+
"what": "urn:bsv:vsc:term:what",
|
|
16
|
+
"when": "urn:bsv:vsc:term:when",
|
|
17
|
+
"where": "urn:bsv:vsc:term:where",
|
|
18
|
+
"who": "urn:bsv:vsc:term:who",
|
|
19
|
+
"how": "urn:bsv:vsc:term:how",
|
|
20
|
+
"scheme": "urn:bsv:vsc:term:scheme",
|
|
21
|
+
"value": "urn:bsv:vsc:term:value",
|
|
22
|
+
"schemeAuthority": "urn:bsv:vsc:term:schemeAuthority",
|
|
23
|
+
"serialNumber": "urn:bsv:vsc:term:serialNumber",
|
|
24
|
+
"batchOrLot": "urn:bsv:vsc:term:batchOrLot",
|
|
25
|
+
"expiryDate": "urn:bsv:vsc:term:expiryDate",
|
|
26
|
+
"quantity": "urn:bsv:vsc:term:quantity",
|
|
27
|
+
"quantityUnit": "urn:bsv:vsc:term:quantityUnit",
|
|
28
|
+
"eventTime": "urn:bsv:vsc:term:eventTime",
|
|
29
|
+
"recordedAt": "urn:bsv:vsc:term:recordedAt",
|
|
30
|
+
"timezone": "urn:bsv:vsc:term:timezone",
|
|
31
|
+
"timePrecision": "urn:bsv:vsc:term:timePrecision",
|
|
32
|
+
"jurisdiction": "urn:bsv:vsc:term:jurisdiction",
|
|
33
|
+
"actorRole": "urn:bsv:vsc:term:actorRole",
|
|
34
|
+
"eventType": "urn:bsv:vsc:term:eventType",
|
|
35
|
+
"eventTypeVocab": "urn:bsv:vsc:term:eventTypeVocab",
|
|
36
|
+
"businessStep": "urn:bsv:vsc:term:businessStep",
|
|
37
|
+
"disposition": "urn:bsv:vsc:term:disposition",
|
|
38
|
+
"action": "urn:bsv:vsc:term:action",
|
|
39
|
+
"chainOfCustody": "urn:bsv:vsc:term:chainOfCustody",
|
|
40
|
+
"sequenceNumber": "urn:bsv:vsc:term:sequenceNumber",
|
|
41
|
+
"topology": "urn:bsv:vsc:term:topology",
|
|
42
|
+
"topologyNote": "urn:bsv:vsc:term:topologyNote",
|
|
43
|
+
"actorDid": {
|
|
44
|
+
"@id": "urn:bsv:vsc:term:actorDid",
|
|
45
|
+
"@type": "@id"
|
|
46
|
+
},
|
|
47
|
+
"assertionMethod": {
|
|
48
|
+
"@id": "urn:bsv:vsc:term:assertionMethod",
|
|
49
|
+
"@type": "@id"
|
|
50
|
+
},
|
|
51
|
+
"chainId": {
|
|
52
|
+
"@id": "urn:bsv:vsc:term:chainId",
|
|
53
|
+
"@type": "@id"
|
|
54
|
+
},
|
|
55
|
+
"correctionOf": {
|
|
56
|
+
"@id": "urn:bsv:vsc:term:correctionOf",
|
|
57
|
+
"@type": "@id"
|
|
58
|
+
},
|
|
59
|
+
"originalIssuer": {
|
|
60
|
+
"@id": "urn:bsv:vsc:term:originalIssuer",
|
|
61
|
+
"@type": "@id"
|
|
62
|
+
},
|
|
63
|
+
"productIdentifiers": {
|
|
64
|
+
"@id": "urn:bsv:vsc:term:productIdentifiers",
|
|
65
|
+
"@container": "@set"
|
|
66
|
+
},
|
|
67
|
+
"parentSeals": {
|
|
68
|
+
"@id": "urn:bsv:vsc:term:parentSeals",
|
|
69
|
+
"@type": "@id",
|
|
70
|
+
"@container": "@set"
|
|
71
|
+
},
|
|
72
|
+
"childSeals": {
|
|
73
|
+
"@id": "urn:bsv:vsc:term:childSeals",
|
|
74
|
+
"@type": "@id",
|
|
75
|
+
"@container": "@set"
|
|
76
|
+
},
|
|
77
|
+
"predecessorCredentials": {
|
|
78
|
+
"@id": "urn:bsv:vsc:term:predecessorCredentials",
|
|
79
|
+
"@type": "@id",
|
|
80
|
+
"@container": "@set"
|
|
81
|
+
},
|
|
82
|
+
"extensions": {
|
|
83
|
+
"@id": "urn:bsv:vsc:term:extensions",
|
|
84
|
+
"@type": "@json"
|
|
85
|
+
},
|
|
86
|
+
"classifications": {
|
|
87
|
+
"@id": "urn:bsv:vsc:term:classifications",
|
|
88
|
+
"@type": "@json"
|
|
89
|
+
},
|
|
90
|
+
"readPoint": {
|
|
91
|
+
"@id": "urn:bsv:vsc:term:readPoint",
|
|
92
|
+
"@type": "@json"
|
|
93
|
+
},
|
|
94
|
+
"businessLocation": {
|
|
95
|
+
"@id": "urn:bsv:vsc:term:businessLocation",
|
|
96
|
+
"@type": "@json"
|
|
97
|
+
},
|
|
98
|
+
"geoCoordinates": {
|
|
99
|
+
"@id": "urn:bsv:vsc:term:geoCoordinates",
|
|
100
|
+
"@type": "@json"
|
|
101
|
+
},
|
|
102
|
+
"actorLicense": {
|
|
103
|
+
"@id": "urn:bsv:vsc:term:actorLicense",
|
|
104
|
+
"@type": "@json"
|
|
105
|
+
},
|
|
106
|
+
"permittedEventTypes": {
|
|
107
|
+
"@id": "urn:bsv:vsc:term:permittedEventTypes",
|
|
108
|
+
"@type": "@json"
|
|
109
|
+
},
|
|
110
|
+
"permittedProductSchemes": {
|
|
111
|
+
"@id": "urn:bsv:vsc:term:permittedProductSchemes",
|
|
112
|
+
"@type": "@json"
|
|
113
|
+
},
|
|
114
|
+
"permittedJurisdictions": {
|
|
115
|
+
"@id": "urn:bsv:vsc:term:permittedJurisdictions",
|
|
116
|
+
"@type": "@json"
|
|
117
|
+
},
|
|
118
|
+
"permittedRecordIds": {
|
|
119
|
+
"@id": "urn:bsv:vsc:term:permittedRecordIds",
|
|
120
|
+
"@type": "@json"
|
|
121
|
+
},
|
|
122
|
+
"permittedActions": {
|
|
123
|
+
"@id": "urn:bsv:vsc:term:permittedActions",
|
|
124
|
+
"@type": "@json"
|
|
125
|
+
}
|
|
126
|
+
}
|
|
127
|
+
}
|