You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/basics/identifiers.md
+18-6Lines changed: 18 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,11 +3,17 @@ id: identifiers
3
3
title: Identifiers
4
4
---
5
5
6
-
`Decentralized Identifier` or `DID` is a critical component of verifiable data. A `DID` is a new type of unique identifier which can be created independent of a central authority and that is designed to prove control over the DID using cryptographic proofs. In a verifiable data context, a DID can be used to verify the provenance and ownership of attested data by verifying the proof that is attached to the assertion.
6
+
`Decentralized Identifier` or `DID` is a critical component of verifiable data. A `DID` is a new type of unique
7
+
identifier which can be created independent of a central authority and that is designed to prove control over the DID
8
+
using cryptographic proofs. In a verifiable data context, a DID can be used to verify the provenance and ownership of
9
+
attested data by verifying the proof that is attached to the assertion.
7
10
8
11
## Decentralized Identifier
9
12
10
-
Different flavors of `DIDs` exist today. The flavor of a `DID` or more accurately the `DID Method` defines how CRUD operations for a DID of that `DID Method` are executed. Each `DID Method` has different tradeoffs in specific use cases. For example, a web DID can be created without a Blockchain but `DID Methods` exist that have a dependency on a Blockchain. All of them are valid `DIDs` but have different guaranteees.
13
+
Different flavors of `DIDs` exist today. The flavor of a `DID` or more accurately the `DID Method` defines how CRUD
14
+
operations for a DID of that `DID Method` are executed. Each `DID Method` has different tradeoffs in specific use cases.
15
+
For example, a web DID can be created without a Blockchain but `DID Methods` exist that have a dependency on a
16
+
Blockchain. All of them are valid `DIDs` but have different guaranteees.
11
17
12
18
The example below shows how a web DID for veramo.dev might look like.
13
19
@@ -17,15 +23,21 @@ did:web:veramo.dev
17
23
18
24
### DID Creation
19
25
20
-
When a `DID` is created, it is typically associated with a private and public key pair. The public key will be visible in the `DID Document`. This allows the controller/subject of the `DID` to generate proofs that are verifiable by anyone that has the corresponding `DID Document` for that `DID`. The process of retrieving the `DID Document` from a `DID` is called `DID Resolution`.
26
+
When a `DID` is created, it is typically associated with a private and public key pair. The public key will be visible
27
+
in the `DID Document`. This allows the controller/subject of the `DID` to generate proofs that are verifiable by anyone
28
+
that has the corresponding `DID Document` for that `DID`. The process of retrieving the `DID Document` from a `DID` is
29
+
called `DID Resolution`.
21
30
22
31
### DID Resolution
23
32
24
-
A `DID Resolver` can take `DID` as input and resolve the `DID Document`. This is an important concept in how data flows in verifiable data systems.
33
+
A `DID Resolver` can take `DID` as input and resolve the `DID Document`. This is an important concept in how data flows
34
+
in verifiable data systems.
25
35
26
36
### DID Document
27
37
28
-
Every `DID` has a `DID Document` that describes the `DID` subject. In the case of `did:web` the `DID Document` is hosted on the website in the following format. It contains essential cryptographic information and also services that the `DID` has available. This is the foundation of how `DIDs` can start to communicate with each other.
38
+
Every `DID` has a `DID Document` that describes the `DID` subject. In the case of `did:web` the `DID Document` is hosted
39
+
on the website in the following format. It contains essential cryptographic information and also services that the `DID`
40
+
has available. This is the foundation of how `DIDs` can start to communicate with each other.
29
41
30
42
```json
31
43
// 20201110152830
@@ -61,4 +73,4 @@ Every `DID` has a `DID Document` that describes the `DID` subject. In the case o
61
73
62
74
### DID Methods
63
75
64
-
Explainer on what a DID method is and links to supported [DID Methods](/docs/veramo_agent/did_methods) page
76
+
Explainer on what a DID method is and links to supported [DID Methods](../veramo_agent/did_methods.md) page
Copy file name to clipboardExpand all lines: docs/basics/introduction.md
+32-11Lines changed: 32 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,34 +6,55 @@ sidebar_label: Introduction
6
6
7
7
:::info
8
8
9
-
Veramo is in a public beta. There will be some breaking changes in the coming months, and we endeavor to communicate these in advance via our blog. However, we expect the core APIs to remain relatively stable. You can keep up to date here and get involved in our growing community. We are excited to see what you build with Veramo!
9
+
Veramo is in a public beta. There will be some breaking changes in the coming months, and we endeavor to communicate
10
+
these in advance via our blog. However, we expect the core APIs to remain relatively stable. You can keep up to date
11
+
here and get involved in our growing community. We are excited to see what you build with Veramo!
10
12
11
13
:::
12
14
13
-
Veramo is a JavaScript framework that makes it easy for anyone to use cryptographically verifiable data in their applications. It was designed to make it easy for developers who want to use DIDs, verifiable credentials, and data-centric protocols to bring next-generation features to their users.
15
+
Veramo is a JavaScript framework that makes it easy for anyone to use cryptographically verifiable data in their
16
+
applications. It was designed to make it easy for developers who want to use DIDs, verifiable credentials, and
17
+
data-centric protocols to bring next-generation features to their users.
14
18
15
-
These docs are written for anyone wishing to learn more about the grounding principles behind verifiable data and develop a deeper understanding of the Veramo framework to build next-generation apps that leverage the many benefits of trust networks.
19
+
These docs are written for anyone wishing to learn more about the grounding principles behind verifiable data and
20
+
develop a deeper understanding of the Veramo framework to build next-generation apps that leverage the many benefits of
21
+
trust networks.
16
22
17
23
### How to use these docs
18
24
19
-
If you are new to the concept of verifiable data, it would be best to read the fundamentals section linearly as each section builds on knowledge and terminology gained in the previous.
25
+
If you are new to the concept of verifiable data, it would be best to read the fundamentals section linearly as each
26
+
section builds on knowledge and terminology gained in the previous.
20
27
21
-
If you are more experienced with verifiable data concepts and/or development in general, you can dive into the architecture section where more specifics of how the internals work is covered. You can also jump over to the [API reference](/docs/api/core) section. Links and more info about these packages can also be found in the [Plugins](/docs/veramo_agent/plugins) section.
28
+
If you are more experienced with verifiable data concepts and/or development in general, you can dive into the
29
+
architecture section where more specifics of how the internals work is covered. You can also jump over to
30
+
the [API reference](../api/index.md) section. Links and more info about these packages can also be found in
31
+
the [Plugins](../veramo_agent/plugins.md) section.
22
32
23
33
### Mission
24
34
25
35
> Our mission is to empower developers to build better trust layers in their applications.
26
36
27
-
We obsess over standards and interop so developers and product owners can focus on building their next-generation applications that leverage verifiable data and their decentralized verification benefits.
37
+
We obsess over standards and interop so developers and product owners can focus on building their next-generation
38
+
applications that leverage verifiable data and their decentralized verification benefits.
28
39
29
40
### Why Veramo?
30
41
31
-
The verifiable data landscape has grown exponentially in the past few years and continues to grow at an accelerated rate. Where you have accelerated innovation, you will also have a lot of competing standards. This anomaly makes interoperability challenging. Veramo was designed to be flexible, modular, and scalable. It allows developers to orchestrate a custom system from a growing list of standards without worrying about interoperability and fast-changing specs.
42
+
The verifiable data landscape has grown exponentially in the past few years and continues to grow at an accelerated
43
+
rate. Where you have accelerated innovation, you will also have a lot of competing standards. This anomaly makes
44
+
interoperability challenging. Veramo was designed to be flexible, modular, and scalable. It allows developers to
45
+
orchestrate a custom system from a growing list of standards without worrying about interoperability and fast-changing
46
+
specs.
32
47
33
-
Competing standards can create an unnecessary burden and confusion for product owners and developers who prefer not to be tied to a specific vendor or invest too much building on standards that will most likely change. There is a complex [dependency tree](/docs/advanced/data_flow) per platform on top of changing standards that requires considerable effort to manage.
48
+
Competing standards can create an unnecessary burden and confusion for product owners and developers who prefer not to
49
+
be tied to a specific vendor or invest too much building on standards that will most likely change. There is a complex
50
+
dependency tree per platform on top of changing standards that requires considerable effort to manage.
34
51
35
-
However, this should not prevent businesses from bringing the immense value of verifiable data to their users. We envision an ecosystem of interoperable functionality made possible through specialized community plugins that respect open standards.
52
+
However, this should not prevent businesses from bringing the immense value of verifiable data to their users. We
53
+
envision an ecosystem of interoperable functionality made possible through specialized community plugins that respect
54
+
open standards.
36
55
37
-
At Veramo, we work closely with the [W3C](https://www.w3.org/) and [DIF](https://identity.foundation/) to build compatibility across many projects and initiatives in the space.
56
+
At Veramo, we work closely with the [W3C](https://www.w3.org/) and [DIF](https://identity.foundation/) to build
57
+
compatibility across many projects and initiatives in the space.
38
58
39
-
Using Veramo, you can design your agent how you want it by using the [core plugins](/docs/veramo_agent/plugins). We have plugins for DID Methods, Messaging Protocols, Storage, Key Management, Authentication, and many more.
59
+
Using Veramo, you can design your agent how you want it by using the [core plugins](../veramo_agent/plugins.md). We have
60
+
plugins for DID Methods, Messaging Protocols, Storage, Key Management, Authentication, and many more.
Copy file name to clipboardExpand all lines: docs/basics/signing_keys.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,8 @@ id: signing_keys
3
3
title: Signing & Keys
4
4
---
5
5
6
-
To understand how verifiable data works it is important to have an understanding public keys and signing. The following videos provide an excellent overview.
6
+
To understand how verifiable data works it is important to have an understanding public keys and signing. The following
7
+
videos provide an excellent overview.
7
8
8
9
Robert Miles PhD Student at University of Nottingham
Copy file name to clipboardExpand all lines: docs/basics/verifiable_data.md
+30-11Lines changed: 30 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,30 +3,48 @@ id: verifiable_data
3
3
title: Verifiable Data
4
4
---
5
5
6
-
Verifiable data is simply data that has been digitally signed using a cryptographic algorithm. If data has been signed in this way, someone can verify the signature. Here we can look a the most common standard of verifiable data - Verifiable Credentials.
6
+
Verifiable data is simply data that has been digitally signed using a cryptographic algorithm. If data has been signed
7
+
in this way, someone can verify the signature. Here we can look a the most common standard of verifiable data -
8
+
Verifiable Credentials.
7
9
8
10
### W3C Verifiable Credential
9
11
10
-
To summarise the W3C definition of a [Verifiable Credential](https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential), it is a piece of data that conforms to the `VerifiableCredential` type. It has attributes such as issuer, subject, proofs, and data being made verifiable. Like a physical credential, a verifiable credential is issued from one entity known as the `issuer` to another entity, the `subject`.
12
+
To summarise the W3C definition of
13
+
a [Verifiable Credential](https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential), it is a piece of data
14
+
that conforms to the `VerifiableCredential` type. It has attributes such as issuer, subject, proofs, and data being made
15
+
verifiable. Like a physical credential, a verifiable credential is issued from one entity known as the `issuer` to
16
+
another entity, the `subject`.
11
17
12
-
Let's imagine a physical document such as a passport or driver's license; these documents can be issued by the government that asserts your personal information and 'permissions' such as the type of vehicle you can drive or if you can vote. A physical credential has encoded watermarks, which can be scanned to prove that the issuer is who is stated on the document. To trust the document, you would need to trust the issuer of the document. Some facilities will have the ability to scan these documents to verify the authenticity of the document. This would be considered a 'trust network'.
18
+
Let's imagine a physical document such as a passport or driver's license; these documents can be issued by the
19
+
government that asserts your personal information and 'permissions' such as the type of vehicle you can drive or if you
20
+
can vote. A physical credential has encoded watermarks, which can be scanned to prove that the issuer is who is stated
21
+
on the document. To trust the document, you would need to trust the issuer of the document. Some facilities will have
22
+
the ability to scan these documents to verify the authenticity of the document. This would be considered a 'trust
23
+
network'.
13
24
14
-
You trust the government and the scanner they approve; therefore, you will trust the person whose document is verified by the scanner. The same model exists here, except the verification or proof is purely digital and cryptographic. Also, it should be noted when anything moves from analog to digital, it usually has more applications outside of the traditional analog version.
25
+
You trust the government and the scanner they approve; therefore, you will trust the person whose document is verified
26
+
by the scanner. The same model exists here, except the verification or proof is purely digital and cryptographic. Also,
27
+
it should be noted when anything moves from analog to digital, it usually has more applications outside of the
28
+
traditional analog version.
15
29
16
30
This is the current v1 format for a W3C compliant Verifiable Credential:
17
31
18
32
```json
19
33
{
20
34
"@context": [
21
-
"https://www.w3.org/2018/credentials/v1",
35
+
"https://www.w3.org/2018/credentials/v1"
22
36
],
23
-
"type": ["VerifiableCredential"],
24
-
"issuer": {"id": "did:web:veramo.dev"},
37
+
"type": [
38
+
"VerifiableCredential"
39
+
],
40
+
"issuer": {
41
+
"id": "did:web:veramo.dev"
42
+
},
25
43
"issuanceDate": "2010-01-01T19:73:24Z",
26
44
"credentialSubject": {
27
45
"id": "did:example:user",
28
46
"community": {
29
-
"rank": "rockstar"
47
+
"rank": "rockstar"
30
48
}
31
49
},
32
50
"proof": {
@@ -35,9 +53,10 @@ This is the current v1 format for a W3C compliant Verifiable Credential:
0 commit comments