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
Background:
The current DID specification focuses on providing a decentralized identifier for any subject. However, many applications that utilize DIDs involves physical identification (e.g. location at given time{range}), such as supply chain management, asset tracking, and geospatial services.
Proposal:
I propose extending the DID specification to include fields for GeoJSON, and maybe time(range) and other physical data.
GeoJSON is a widely used format for encoding geographic data structures. Incorporating GeoJSON fields into DIDs will allow for the representation of points, lines, polygons, and other geographical features directly within the DID document.
Specific Changes:
• Introduce a new geoJson field in the DID document to store geographic data.
• The geoJson field should accept any valid GeoJSON object, such as Point, LineString, Polygon, etc.
• Example of how the DID document might look with a GeoJSON field:
• Tracking the geographic location of assets in a supply chain.
• Associating specific DIDs with physical locations, such as landmarks or facilities.
• Enhancing geospatial services with decentralized identifiers.
Impact:
• This extension will significantly enhance the utility of DIDs for use cases that require geographic data, promoting broader adoption in sectors like logistics, environmental monitoring, and smart cities.
The text was updated successfully, but these errors were encountered:
@entin-hun, while this extension would be possible for DIDs it is not how they were intended to be used.
DIDs are a type of identifier that can be used to identity people, things or abstract concepts.
DIDs resolve to DID documents containing cryptographic material and lists service endpoints for the purposes of verifying cryptographic proofs from, and interacting with, the controller of an identifier.
Once you have identified something, you can describe/characterise that thing. A common way to do this is to combine DIDs with Verifiable Credentials - https://w3c.github.io/vc-data-model/ - which allow anyone to make statements about anything.
For example in your usecase:
Tracking the geographic location of assets in a supply chain.
The DID may identify the asset e.g. did:example:123456789. A VC could then be created like this:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://somegeojson/context"
],
"type": ["VerifiableCredential", "Location"],
"issuer": "did:example:123456789", // Issuer could either be the asset itself, self attesting to location. Or some other entity, identified by a different DID."validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:123456789",
"geoJson": {
"type": "Point",
"coordinates": [125.6, 10.1]
}
}
"proof" : {...}
}
In this way we can associate identifiers with a set of cryptographically verifiable statements describing the identifier made by different entities. This allows answers to the question who is saying the asset identified by did:example:123456789 is at a specific location and when they said it.
I believe all your geographic use cases could be addressed in this manner.
Background:
The current DID specification focuses on providing a decentralized identifier for any subject. However, many applications that utilize DIDs involves physical identification (e.g. location at given time{range}), such as supply chain management, asset tracking, and geospatial services.
Proposal:
I propose extending the DID specification to include fields for GeoJSON, and maybe time(range) and other physical data.
GeoJSON is a widely used format for encoding geographic data structures. Incorporating GeoJSON fields into DIDs will allow for the representation of points, lines, polygons, and other geographical features directly within the DID document.
Specific Changes:
Use Cases:
Impact:
The text was updated successfully, but these errors were encountered: