decentralized-identity / universal-resolver

Universal Resolver implementation and drivers.

Universal Resolver

The Universal Resolver resolves Decentralized Identifiers (DIDs) across many different DID methods, based on the W3C DID Core 1.0 and DID Resolution specifications. It is a work item of the DIF Identifiers&Discovery Working Group.

See this blog post and this webinar for an introduction.

See https://dev.uniresolver.io/ for a DIF-hosted instance of the Universal Resolver that can be used for testing purposes. See Docker Hub for images.

Quick Start

You can deploy the Universal Resolver on your local machine by cloning this Github repository, and using docker-compose to build and run the Universal Resolver as well as its drivers.

git clone https://github.com/decentralized-identity/universal-resolver
cd universal-resolver/
docker-compose -f docker-compose.yml pull
docker-compose -f docker-compose.yml up

You should then be able to resolve identifiers locally using simple curl requests as follows:

curl -X GET http://localhost:8080/1.0/identifiers/did:jwk:eyJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpGZk1iek9qTW1RNGVmVDZrdndUSUpqZWxUcWpsMHhqRUlXUTJxb2JzUk1NIiwia3R5IjoiT0tQIiwiY3J2IjoiRWQyNTUxOSIsImFsZyI6IkVkRFNBIiwieCI6IkFOUmpIX3p4Y0tCeHNqUlBVdHpSYnA3RlNWTEtKWFE5QVBYOU1QMWo3azQifQ
curl -X GET http://localhost:8080/1.0/identifiers/did:dyne:demo:FFqGYxShyDGAHd4QyLY1KFCSGBb1mBP9sZebEyBM7JPi
curl -X GET http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
curl -X GET http://localhost:8080/1.0/identifiers/did:btcr:xz35-jznz-q6mr-7q6
curl -X GET http://localhost:8080/1.0/identifiers/did:v1:test:nym:z6Mkmpe2DyE4NsDiAb58d75hpi1BjqbH6wYMschUkjWDEEuR
curl -X GET http://localhost:8080/1.0/identifiers/did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6
curl -X GET http://localhost:8080/1.0/identifiers/did:web:did.actor:alice
curl -X GET http://localhost:8080/1.0/identifiers/did:web:did.actor:bob
curl -X GET http://localhost:8080/1.0/identifiers/did:web:did.actor:mike
curl -X GET http://localhost:8080/1.0/identifiers/did:ethr:mainnet:0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736
curl -X GET http://localhost:8080/1.0/identifiers/did:ethr:goerli:0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736
curl -X GET http://localhost:8080/1.0/identifiers/did:ethr:0x5:0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736
curl -X GET http://localhost:8080/1.0/identifiers/did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71
curl -X GET http://localhost:8080/1.0/identifiers/did:ethr:ewc:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71
curl -X GET http://localhost:8080/1.0/identifiers/did:ens:vitalik.eth
curl -X GET http://localhost:8080/1.0/identifiers/did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludDEiLCJyIjpbImRpZDpleGFtcGxlOnNvbWVtZWRpYXRvciNzb21la2V5MSJdLCJhIjpbImRpZGNvbW0vdjIiLCJkaWRjb21tL2FpcDI7ZW52PXJmYzU4NyJdfQ
curl -X GET http://localhost:8080/1.0/identifiers/did:eosio:eos:eoscanadacom
curl -X GET http://localhost:8080/1.0/identifiers/did:eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11:caleosblocks
curl -X GET http://localhost:8080/1.0/identifiers/did:jolo:e76fb4b4900e43891f613066b9afca366c6d22f7d87fc9f78a91515be24dfb21
curl -X GET http://localhost:8080/1.0/identifiers/did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0
curl -X GET http://localhost:8080/1.0/identifiers/did:hcr:0f674e7e-4b49-4898-85f6-96176c1e30de
curl -X GET http://localhost:8080/1.0/identifiers/did:neoid:priv:b4eeeb80d20bfb38b23001d0659ce0c1d96be0aa
curl -X GET http://localhost:8080/1.0/identifiers/did:elem:ropsten:EiCtwD11AV9e1oISQRHnMJsBC3OBdYDmx8xeKeASrKaw6A
curl -X GET http://localhost:8080/1.0/identifiers/did:github:gjgd
curl -X GET http://localhost:8080/1.0/identifiers/did:ccp:ceNobbK6Me9F5zwyE3MKY88QZLw
curl -X GET http://localhost:8080/1.0/identifiers/did:ont:AN5g6gz9EoQ3sCNu7514GEghZurrktCMiH
curl -X GET http://localhost:8080/1.0/identifiers/did:kilt:4rNTX3ihuxyWkB7wG3oLgUWSBLa2gva1NBKJsBFm7jJZUYfc
curl -X GET http://localhost:8080/1.0/identifiers/did:factom:testnet:6aa7d4afe4932885b5b6e93accb5f4f6c14bd1827733e05e3324ae392c0b2764
curl -X GET http://localhost:8080/1.0/identifiers/did:mpg:7PGGnRdvKKFftSXU3Jw75Vk5npfg
curl -X GET http://localhost:8080/1.0/identifiers/did:io:0x476c81C27036D05cB5ebfe30ae58C23351a61C4A
curl -X GET http://localhost:8080/1.0/identifiers/did:bba:t:45e6df15dc0a7d91dcccd24fda3b52c3983a214fb0eed0938321c11ec99403cf
curl -X GET http://localhost:8080/1.0/identifiers/did:schema:public-ipfs:json-schema:Qma2beXKwZeiUXcaRaQKwbBV1TqyiJnsMTYExUTdQue43J
curl -X GET http://localhost:8080/1.0/identifiers/did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w
curl -X GET http://localhost:8080/1.0/identifiers/did:gatc:2xtSori9UQZdTqzxrkp7zqKM4Kj5B4C7
curl -X GET http://localhost:8080/1.0/identifiers/did:icon:01:64aa0a2a479cb47afbf2d18d6f9f216bcdcbecdda27ccba3
curl -X GET http://localhost:8080/1.0/identifiers/did:vaa:3wJVWDQWtDFx27FqvSqyo5xsTsxC
curl -X GET http://localhost:8080/1.0/identifiers/did:unisot:1EjHm7VtgsqNzCkvA8XRgGXZ1UKo1txSM4
curl -X GET http://localhost:8080/1.0/identifiers/did:sol:devnet:2eK2DKs6vdzTEoj842Gfcs6DdtffPpw1iF6JbzQL4TuK
curl -X GET http://localhost:8080/1.0/identifiers/did:lit:AEZ87t1bi5bRxmVh3ksMUi
curl -X GET http://localhost:8080/1.0/identifiers/did:ebsi:z25ZZFS7FweHsm9MX2Qvc6gc
curl -X GET http://localhost:8080/1.0/identifiers/did:emtrust:0x242a5ac36676462bd58a
curl -X GET http://localhost:8080/1.0/identifiers/did:meta:0000000000000000000000000000000000000000000000000000000000005e65
curl -X GET http://localhost:8080/1.0/identifiers/did:tz:tz1YwA1FwpgLtc1G8DKbbZ6e6PTb1dQMRn5x
curl -X GET http://localhost:8080/1.0/identifiers/did:pkh:tz:tz2BFTyPeYRzxd5aiBchbXN3WCZhx7BqbMBq
curl -X GET http://localhost:8080/1.0/identifiers/did:orb:hl:uEiBuxTFn4L_Hn8KsOWo8e9kqWP38MThBaToB_5yV3c5QTg:uoQ-BeEJpcGZzOi8vYmFma3JlaWRveXV5d3B5Zjd5NnA0Zmxiem5pNmh4d2prbGQ2N3ltanlpZnV0dWFwN3RzazUzdHNxank:EiD_igS1OSEftg5BGfisJGOS1rgcx5AkQhX0h1B4dHTUYA
curl -X GET http://localhost:8080/1.0/identifiers/did:oyd:zQmaBZTghndXTgxNwfbdpVLWdFf6faYE4oeuN2zzXdQt1kh
curl -X GET http://localhost:8080/1.0/identifiers/did:moncon:z6MkfrVYbLejh9Hv7Qmx4B2P681wBfPFkcHkbUCkgk1Q8LoA
curl -X GET http://localhost:8080/1.0/identifiers/did:dock:5EAp6DB2pkKuAfbhQiqAXFY4XPZkJrvtWKad4ChDmWwDrC8n
curl -X GET http://localhost:8080/1.0/identifiers/did:mydata:z6MkjgVfx2YE7SUBZBej65E7UHSjAyMLukPvdPjPytpTy1ZM
curl -X GET http://localhost:8080/1.0/identifiers/did:dns:danubetech.com
curl -X GET http://localhost:8080/1.0/identifiers/did:indy:idunion:2GMSLg2A8JXcdYVsPC4Jui
curl -X GET http://localhost:8080/1.0/identifiers/did:everscale:47325e80e3cef5922d3a3583ae5c405ded7bda781cb069f2bc932a6c3d6ec62e
curl -X GET http://localhost:8080/1.0/identifiers/did:ala:quor:redT:ec27f358fd0d11d8934ceb51305622ae79b6ad15
curl -X GET http://localhost:8080/1.0/identifiers/did:cheqd:mainnet:Ps1ysXP2Ae6GBfxNhNQNKN
curl -X GET http://localhost:8080/1.0/identifiers/did:com:1l6zglh8pvcrjtahsvds2qmfpn0hv83vn8f9cf3
curl -X GET http://localhost:8080/1.0/identifiers/did:kscirc:k12NqvVM9BX6AaMjPK1hUTUkKBWPBAUXAszTxdx7jDZPv4iqCZ1D
curl -X GET http://localhost:8080/1.0/identifiers/did:iscc:miagwptv4j2z57ci
curl -X GET http://localhost:8080/1.0/identifiers/did:ev:bmM8apgHQD8cPbwNsMSJKqkYRCDYhkK55uxR9
curl -X GET http://localhost:8080/1.0/identifiers/did:iid:3QUs61mk7a9CdCpckriQbA5emw8pubj6RMtHXP6gD66YbcungS6w2sa
curl -X GET http://localhost:8080/1.0/identifiers/did:evan:testcore:0x126E901F6F408f5E260d95c62E7c73D9B60fd734
curl -X GET http://localhost:8080/1.0/identifiers/did:bid:ef214PmkhKndUcArDQPgD5J4fFVwqJFPt
curl -X GET http://localhost:8080/1.0/identifiers/did:polygonid:polygon:amoy:2qZBvRQPTZwYEKDVT3xY8W8zXvznqykyeqjSmXdz4U
curl -X GET http://localhost:8080/1.0/identifiers/did:pdc:8801:0xf47b66bc0d9b7c73f9ff27bf1f49a2b69dc167fc
curl -X GET http://localhost:8080/1.0/identifiers/did:tys:4B4AbVzzcJSnCZsdX4VaKyQgHRnC
curl -X GET http://localhost:8080/1.0/identifiers/did:plc:yk4dd2qkboz2yv6tpubpc6co
curl -X GET http://localhost:8080/1.0/identifiers/did:evrc:issuer:polygon:62eeb90e-eee4-4d31-8927-1075e82b2a74
curl -X GET http://localhost:8080/1.0/identifiers/did:keri:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP
curl -X GET http://localhost:8080/1.0/identifiers/did:webs:peacekeeper.github.io:did-webs-iiw-tutorial:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP
curl -X GET http://localhost:8080/1.0/identifiers/did:content:3SqTXtoMpiPeNo5vEP2p7yNGQUeCGjqW1wnctv8yaCWXojD29GYcUEo
curl -X GET http://localhost:8080/1.0/identifiers/did:algo:mainnet:app:1845671812:da490f2d15a625459bf970a3d55e1a646dfd3a956d011546e953e945d39fdada
curl -X GET http://localhost:8080/1.0/identifiers/did:itn:PA7xLNkMAqzzrDp4UBnrZm
curl -X GET http://localhost:8080/1.0/identifiers/did:iota:0xf4d6f08f5a1b80dd578da7dc1b49c886d580acd4cf7d48119dfeb82b538ad88a
curl -X GET http://localhost:8080/1.0/identifiers/did:iden3:polygon:amoy:xC8VZLUUfo5p9DWUawReh7QSstmYN6zR7qsQhQCsw

You can also use an "Accept" header to request the DID document in a specific representation, e.g.:

curl -H "Accept: application/did+ld+json" https://dev.uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
curl -H "Accept: application/did+json" https://dev.uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
curl -H "Accept: application/did+cbor" https://dev.uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

If this doesn't work, see Troubleshooting.

Note that there is also a Universal Resolver frontend that can optionally be installed separately.

It is possible to "deep link" to the resolution result of a specific DID as follows:

https://dev.uniresolver.io/#did:indy:sovrin:WRfXPg8dantKVubE3HX8pw

Drivers

Are you developing a DID method and Universal Resolver driver? Click Driver Development for instructions.

Driver Name	Driver Version	DID Method Spec Version	Docker Image or URL	Description
did-btcr	0.1-SNAPSHOT	0.1	universalresolver/driver-did-btcr	Bitcoin Reference
did-sov	0.1-SNAPSHOT	0.1	universalresolver/driver-did-sov	Sovrin public ledger
did-stack	0.1	1.0	universalresolver/driver-did-stack
did-dom	0.1-SNAPSHOT	(missing)	universalresolver/driver-did-dom
did-ethr	5.0.0	10.1.0	uport/uni-resolver-driver-did-uport	Ethereum addresses or secp256k1 publicKeys
did-ens	5.0.0	0.1.1	uport/uni-resolver-driver-did-uport	ENS names
did-web	5.0.0	3.0.0	uport/uni-resolver-driver-did-uport	Domain name
did-peer	5.0.0	1.0-draft	uport/uni-resolver-driver-did-uport	Peer DID
did-eosio	0.1.3	0.1	gimlyblockchain/eosio-universal-resolver-driver	EOSIO blockchain platform
did-v1	0.1	1.0	veresone/uni-resolver-did-v1-driver	Veres One Blockchain
did-jolo	0.1	0.1	jolocomgmbh/jolocom-did-driver	Jolocom identity management
did-hacera	0.1	(missing)	hacera/hacera-did-driver	HACERA autonomous data exchange network
did-elem	1.0.0	1.0		Sidetree protocol (Ethereum and IPFS)
did-seraphid	0.1	(missing)	swisscomblockchainag/seraph-id-did-driver	Seraph ID (SSI solution on the NEO blockchain platform)
did-github	0.1	(missing)		Github
did-ccp	0.1-SNAPSHOT	0.1	hello2mao/driver-did-ccp	Baidu Cloud
did-ont	0.1	1.0	ontio/ontid-driver	Ontology ONT ID
did-kilt	2.5.0	1.3	kiltprotocol/kilt-did-driver	KILT Protocol
did-factom	0.2.0-SNAPSHOT	1.0	sphereon/uni-resolver-driver-did-factom	Factom Protocol
did-key	1.0.0	0.7	universalresolver/driver-did-key	Public keys (in general)
did-io	0.1.0	(missing)	iotex/uni-resolver-driver-did-io	IoTeX Network
did-bba	0.2.2	1.0	blobaa/bba-did-driver	Blobaa blockchain-based authentication on the Ardor blockchain
did-schema	0.1.1	0.1	51nodes/schema-registry-did-resolver	Identify and address schema definitions in a schema registry
did-ion	0.8.1	0.1	identityfoundation/driver-did-ion	ION network (Sidetree implementation on top of Bitcoin)
did-ace	1.0	(missing)	aceblock/ace-did-driver	AceBlock blockchain framework
did-gatc	2.0.0	1.0 WD	gatacaid/universal-resolver-driver	GATACA (blockchain-agnostic digital identity platform)
did-icon-zzeung	0.1.2	1.0 WD	amuyu/driver-did-icon	ICON decentralized network
did-vaa	1.0.0	1.0 WD	caict/driver-did-vaa	BIF blockchain
did-unisot	1.0.0	1.0.0	unisot/unisot-did-driver	UNISOT distributed identity system (atop Bitcoin SV blockchain)
did-sol	3.3.0	3.3.0	identitydotcom/driver-did-sol	Solana blockchain
did-lit	0.1.1	0.1.1	ibct/driver-did-lit	LEDGIS blockchain
did-ebsi	2.0.0	2.0.0	URL	EBSI Platform (European Blockchain Services Infrastructure)
did-emtrust	0.1	0.1	halialabsdev/emtrust_did_driver	EmTrust WAI distributed identity system
did-meta	1.0	1.0	URL	Metadium Decentralized Identifiers
did-tz	0.1.0	0.1	ghcr.io/spruceid/didkit-http	Tezos DID method
did-pkh	0.0.1	0.1	ghcr.io/spruceid/didkit-http	Public Key Hash DID method
did-orb	v1.0.0-rc3	0.2	trustbloc/orb-did-driver	Orb DID method
did-oyd	0.4.5	0.4	oydeu/oydid-resolver	self-sustained environment for managing DIDs
did-moncon	0.4	0.3	camicasii/didresolver-g
did-dock	1.0.0	1.0 WD	0.1	docknetwork/dock-did-driver
did-mydata	1.3	1.1 WD	igrantio/uni-resolver-driver-did-mydata	iGrant.io
did-dns	0.1-SNAPSHOT	0.1	universalresolver/driver-did-dns	Domain name
did-indy	0.9.0	0.1	universalresolver/driver-did-indy	Hyperledger Indy
did-everscale	0.1	0.1	radianceteamssi/everscale-did-resolver-driver	Everscale Blockchain
did-alastria-mvp2	1.0.0	MVP2	alastria/universal-resolver	AlastriaID MVP2
did-cheqd	3.6.1	1.0	cheqd/did-resolver	cheqd network
did-com	1.0.0	1.0	ghcr.io/commercionetwork/uni-resolver-driver-did-com	Commercio public ledger
did-dyne	0.1	1.0	dyne/w3c-did-driver	Dyne.org Decentralized Identifiers
did-jwk	0.1	1.0	transmute/restricted-resolver	DID Json Web Key
did-kscirc	0.1	1.0	k4security/kschain-resolver	KSChain blockchain
did-iscc	0.1.0	0.1	ghcr.io/iscc/iscc-did-driver	International Standard Content Code - ISCC
did-ev	1.0.4	0.1	ghcr.io/kaytrust/driver-did-ev	KayTrust default method based on Ethereum smart contracts
did-iid	0.1.0	0.1	zoeyian/driver-did-iid:latest	Inspur DID Method
did-evan	0.1.2	0.9	evannetwork/evan-did-driver	evan.network
did-bid	2.0.0	2.0 WD	caictdevelop/driver-did-bid	BIF blockchain
did-polygonid	0.0.4	1.0.0	ghcr.io/iden3/driver-did-iden3:v0.0.4	PolygonID DID
did-pdc	0.0.1	(missing)	w744219971/driver-did-pdc	PDC DID
did-tys	1.0	1.0	itpeoplecorp/tys-did-driver	TYS DID
did-plc	0.0.1	dev	bnewbold/uni-resolver-driver-did-plc	PLC DID
did-evrc	1.0	1.0	viitorcloud/uni-resolver-driver-did-evrc	EveryCRED DID Method
did-keri	0.1	0.1	gleif/did-keri-resolver	KERI
did-webs	0.1	0.1	gleif/did-webs-resolver	KER, Web
did-content	0.1	0.1	kataru/content-did-driver	Content DID
did-algo	1.0.0	2.0	ghcr.io/algorandfoundation/did-algo	Algorand Blockchain DID Method
did-itn	1.0.0	1.0	ghcr.io/itn-trust/driver-did-itn	Integrated Trust Network (ITN) DID Method
did-iota	0.1.1	1.0	iotaledger/uni-resolver-driver-iota	IOTA DID
did-iden3	0.0.4	1.0.0	ghcr.io/iden3/driver-did-iden3:v0.0.4	Iden3 DID

More Information

• Driver Development
• Continuous Integration and Delivery
• Development System
• Branching Strategy
• Design Goals
• Troubleshooting
• Java Components

About

Decentralized Identity Foundation - https://identity.foundation/

Supported by NLnet and NGI0 PET, which is made possible with financial support from the European Commission's Next Generation Internet programme.

universal-resolver's Issues

[btcr]DID does not match 4-4-4-3 or 4-4-4-4-2 pattern

Following Quick start, get this error:

Resolve request:

curl -X GET http://localhost:8080/1.0/identifiers/did:btcr:xkrn-xzcr-qqlv-j6sl

error is:

Resolve problem for did:btcr:xkrn-xzcr-qqlv-j6sl: Driver reported for did:btcr:xkrn-xzcr-qqlv-j6sl: DID does not match 4-4-4-3 or 4-4-4-4-2 pattern.%

Driver for /.well-known/did-configuration

Add a driver that can resolve a domain name to a DID, using the /.well-known/did-configuration mechanism:

https://github.com/decentralized-identity/well-known/tree/master/did-configuration

Note that there's already a driver for resolving domain names to DIDs via DNS lookups:

https://github.com/decentralized-identity/universal-resolver/tree/master/drivers/dns
https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/

Caching

How should resolution results be cached?

This could be influenced by:

• Default settings by community consensus and recommendations of the IND WG.
• Custom configuration by the UR administrator.
• Request parameters by a UR user (e.g. to override defaults and force a fresh non-cached lookup).
• Settings associated with the identifier (e.g. TTL setting in the DID document or BNS zone file).

How should the cache be implemented? The UR could cache results in memory, or use a shared caching mechanism such as Blockstack's Atlas peer network.

Add example identifiers which resolve successfully

When I follow the instructions in the blog post, I get 403 errors for all the example identifiers. It would be nice to see successful responses to get a sense for what to expect.

For example:

$ curl -v -X GET http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> GET /1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0

did:ccp:ceNobbK6Me9F5zwyE3MKY88QZLw is not resolvable

did:ccp:3CzQLF3qfFVQ1CjGVzVRZaFXrjAd is not resolvable

Cant get it working with the local indy setup

Hello,

I started the indy sdk by following step 3 in this github url:
https://github.com/hyperledger/indy-sdk/blob/master/README.md#installing-the-sdk
I tried passing all the 4 environment variables and a mixture of them and i get these kind of errors:

If i include the ubuntu binary i get this:
java.lang.UnsatisfiedLinkError: Unable to load library 'indy': Native library (linux-x86-64/libindy.so) not found in resource path ([file:/opt/driver-did-sov/target/test-classes/,......

if i remove the binary environment variable i get this:
Driver reported for did:sov:Th7MpTaRZVRYnPiabds81Y: Cannot create pool config pool1: org.hyperledger.indy.sdk.IOException: An IO error occurred.

I am sure the uniresolver_driver_did_sov_poolGenesisTxn is correct because it is the same path that i use for the indy setup i have referenced above and all the scripts are working.
Please let me know if you can help,
Regards,
Fatjoni

Add JavaScript SDK for the Universal Resolver

As noted in the comments, there are SDKs for python and java here

DIDs must return JSON arrays instead of JSON object

The universal resolver implementation needs to be corrected and updated to reflect the current draft standards definition for the authentication and service properties:

• "The value of the authentication property should be an array of proof mechanisms." (4.4 point 2)
• "The value of the service property should be an array of service endpoints." (4.6 point 2)

Calling the UR with curl http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw returns the following didDocument:

{
	"id": "did:sov:WRfXPg8dantKVubE3HX8pw",
	"service": {
		"type": "xdi",
		"serviceEndpoint": "http://127.0.0.1:8080/xdi"
	},
	"authentication": {
		"type": "Ed25519SignatureAuthentication2018",
		"publicKey": ["did:sov:WRfXPg8dantKVubE3HX8pw#key-1"]
	},
	"publicKey": [{
		"id": "did:sov:WRfXPg8dantKVubE3HX8pw#key-1",
		"type": "Ed25519VerificationKey2018",
		"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}],
	"@context": "https://w3id-temp.org/did/v1"
}

where authentication and service are a JSON object and not a JSON array.

This causes an unecessary verification overhead for people currently using the UR.

Document how to locally test a DID driver

As discussed with @peacekeeper and as a follow-up to this DIF slack thread (https://difdn.slack.com/archives/C4WED8JSH/p1571751145056500):

Driver developers need/want to locally test their dockerized driver before submitting a PR into the Universal Resolver (this) repo. How to do this is not yet documented.

A good place for this might be a new paragraph "Test locally" in universal-resolver/docs/driver-development.md.

publicKeyJwk

When using the context https://www.w3.org/ns/did/v1, the universal resolver seems to remove the publicKeyJwk contents.

I assume there isn't full support for JSON-LD 1.1 and @json in the DID document parser.

Website is down

https://uniresolver.io/

Module build failed: Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (72)

Local names

Should local names be supported by the UR? E.g. if I want to resolve "dan" I may get a different result than if Kyle resolves "dan". This would imply some kind of local state or context to be held by the UR user, such as an address book.

See @ChristopherA 's paper on this topic:
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/linked-local-names.md

Move drivers to a shared folder in this repo

Create a /drivers folder at the root, and move all drivers into it so all implementations can reference them and implementer have a single place to submit updates.

Missing dependencies while compiling the Java resolver

Running mvn compile on the Java Resolver fails to resolve the did-common-java, this is the log:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] uni-resolver
[INFO] uni-resolver-core
[INFO] uni-resolver-driver
[INFO] uni-resolver-driver-http
[INFO] uni-resolver-local
[INFO] uni-resolver-client
[INFO] uni-resolver-web
[INFO] uni-resolver-examples
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building uni-resolver 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ uni-resolver ---
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building uni-resolver-core 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for decentralized-identity:did-common-java:jar:0.1-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] uni-resolver ....................................... SUCCESS [  0.167 s]
[INFO] uni-resolver-core .................................. FAILURE [  0.073 s]
[INFO] uni-resolver-driver ................................ SKIPPED
[INFO] uni-resolver-driver-http ........................... SKIPPED
[INFO] uni-resolver-local ................................. SKIPPED
[INFO] uni-resolver-client ................................ SKIPPED
[INFO] uni-resolver-web ................................... SKIPPED
[INFO] uni-resolver-examples .............................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.387 s
[INFO] Finished at: 2019-06-06T19:31:38-06:00
[INFO] Final Memory: 10M/303M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project uni-resolver-core: Could not resolve dependencies for project decentralized-identity:uni-resolver-core:jar:0.1-SNAPSHOT: Could not find artifact decentralized-identity:did-common-java:jar:0.1-SNAPSHOT -> [Help 1]

Consider REUSE specifications developed by FSFE

I have been contacted via e-mail by the Free Software Foundation Europe (FSFE). They are proposing that we adopt the REUSE specifications developed by the FSFE. They have shared the following links related to this:

• https://download.fsfe.org/NGI0/
• https://reuse.software/

They have also shared the following document:

FSFE - 1 - Best Practices for Software Licensing.pdf

Internal behavior of drivers

We discussed that drivers (both for resolver and registrar) can work in different ways to fulfill their purpose, for example:

1. A resolver driver may have direct access to a full node, or it may use a thin client, or it may call a remote API in order to resolve an identifier. In other words, the driver may be more or less "close" to the source of truth.
2. A registrar driver may or may not require user interaction in order to register an identifier. For example, the "btcr" driver may in a private organizational setting be deployed with a pre-funded wallet shared by all clients, or it may be available publicly but require each client to fund their own wallet. And for example the "sov" driver may be able to act as a "trust anchor" on its own, or it may have to redirect a client to the services of an external trust anchor.

Some points to consider:

• Should there be strictly one driver per DID method, or could there be e.g. two different "btcr" drivers, one for full node support, and one for thin client support?
• Should this be controlled by a driver's configuration (JSON config file, Docker environment variables), so an operator of the resolver/registrar can customize how they want a driver to work?
• This could also be controlled individually for each client request using request parameters, e.g. a client requests that a full node must be used, otherwise abort. (But you have to trust the resolver/registrar to honor those parameters).
• In some cases certain request parameters may be mandatory (e.g. in order to submit a registration request for a "btcr" DID, you need to specify whether you want mainnet or testnet).
• Metadata about the resolution/registration process can be included in the result metadata, e.g. a boolean flag saying that a full node was used. (But you have to trust the resolver/registrar to not lie about this).
• In some cases, both full node mode and thin client mode may be supported, but not actually make a difference in terms of trustworthiness of the result (e.g. state proofs in the "sov" method).

It seems a DID method spec should specify what behavior variations (level of verification, full node vs thin client, etc.) are supported. The individual drivers can then implement this (and may only support a subset of the variations).

The resolver/registrar and their drivers could expose an API that allows clients to discover which variations, configuration settings, request parameters, etc. are supported.

BTCR Resolver Driver appears down

Resolve problem for did:btcr:xxcl-lzpq-q83a-0d5: Cannot retrieve RESOLVE RESULT for did:btcr:xxcl-lzpq-q83a-0d5 from http://driver-did-btcr:8080/1.0/identifiers/did:btcr:xxcl-lzpq-q83a-0d5: Connect to driver-did-btcr:8080 [driver-did-btcr/172.20.0.9] failed: Connection refused (Connection refused)

Update spec/explainer to specify the correct Resolver return object

The return object in the spec/explainer appears out of date, is there somewhere with the current, updated spec that I can use to update the text in this repo?

uni-resolver-web build error

I'm not able to build the uni-resolver-web image using docker build --no-cache -f ./resolver/java/uni-resolver-web/docker/Dockerfile . -t universalresolver/uni-resolver-web. When I try to build it I get the following error:

[ERROR] Failed to execute goal on project uni-resolver-core: Could not resolve dependencies for project decentralized-identity:uni-resolver-core:jar:0.2-SNAPSHOT: Failed to collect dependencies at decentralized-identity:did-common-java:jar:0.1.0: Failed to read artifact descriptor for decentralized-identity:did-common-java:jar:0.1.0: Could not transfer artifact decentralized-identity:did-common-java:pom:0.1.0 from/to github (https://maven.pkg.github.com/decentralized-identity/did-common-java): Transfer failed for https://maven.pkg.github.com/decentralized-identity/did-common-java/decentralized-identity/did-common-java/0.1.0/did-common-java-0.1.0.pom 400 Bad Request -> [Help 1]

I am up-to-date with the current master (48defa6).

Identifier discovery

Should search for identifiers be supported, e.g. return a list of all identifiers that satisfy certain criteria, such as "looking to buy a certain product"? This could involve the use of higher-level functionality such as the DIF Hub protocols or Blockstack storage layer. This may be out of scope for the UR but be implemented elsewhere.

JSON-LD Parsing Error Blocking VC Data Model Integration

https://uniresolver.io/#did:btcr:xxcl-lzpq-q83a-0d5

https://raw.githubusercontent.com/OR13/self/master/ddo.jsonld

Per https://www.w3.org/TR/vc-data-model/#proofs-signatures-0

If the cryptographic suite expects a proofPurpose property, it is expected to exist and be a valid value, such as assertionMethod.

However, assertionMethod is stripped from the btcr did document above by the universal resolver... this cause verification of credentials to fail when using the universal resolver as a document loader.

The solution is not to remove any of the properties defined in https://www.w3.org/ns/did/v1

Wrong version of DID specs in the README

In the Driver section of the README as of commit e5f1418 all drivers declare following DID Spec version 0.11, however the link points to the latest version which is currently 0.13

Can't locate dependencies for `org.hyperledger.indy`

My project is not able to resolve org.hyperledger.indy packages. Need the dependencies for pom.xml as i am not able to find online.

import org.hyperledger.indy.sdk.IndyException;
import org.hyperledger.indy.sdk.LibIndy;
import org.hyperledger.indy.sdk.did.Did;
import org.hyperledger.indy.sdk.did.DidJSONParameters.CreateAndStoreMyDidJSONParameter;
import org.hyperledger.indy.sdk.did.DidResults.CreateAndStoreMyDidResult;
import org.hyperledger.indy.sdk.ledger.Ledger;
import org.hyperledger.indy.sdk.pool.Pool;
import org.hyperledger.indy.sdk.pool.PoolJSONParameters.CreatePoolLedgerConfigJSONParameter;
import org.hyperledger.indy.sdk.pool.PoolJSONParameters.OpenPoolLedgerJSONParameter;
import org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException;
import org.hyperledger.indy.sdk.wallet.Wallet;
import org.hyperledger.indy.sdk.wallet.WalletExistsException;

Can you provide the dependencies for org.hyperledger.indy

did:btcr:x705-jznz-qwvq-0uw is not resolvable

https://uniresolver.io/#did:btcr:xxcl-lzpq-q83a-0d5

Add Better Linking UX

It would be nice to be able to easily link to a Resolved DID.

There should be a button with the text "Share" or similar, that copies a url of the form:

https://uniresolver.io/#did:btcr:xxcl-lzpq-q83a-0d5

It should be accent colored to draw attention to it.

There should also be a QR Code which maps to an endpoint which either resolves to https://uniresolver.io/#did:btcr:xxcl-lzpq-q83a-0d5 or the json representation, depending on request headers.

This will allow clients to decide if they want to show the DID or get its data.

did:v1:test:nym:z6MkuYhA5TN5XGyvFhjhLjBkJ19hY2HnQgwe7h5q1NkK5bjf is not resolvable

Go to https://uniresolver.io/ and try to resolve did:v1:test:nym:z6MkuYhA5TN5XGyvFhjhLjBkJ19hY2HnQgwe7h5q1NkK5bjf from Examples

Not able to resolve testnet.veres.one DID

Universal Resolver is not able to resolve the DID issued on testnet.veres.one.

Resolving DIDs to a specific ledger

In another issue, @peacekeeper wrote this:

I don't think existing DIDs were migrated from the old testnet to the new testnet. Also, as far as I know, there is no way for a resolver to tell which network to use (it's not encoded in the DID itself).

Should DIDs or the DID method (or neither) provide a mechanism for a resolver to know which instance of a ledger (where there is one) to use?

I believe uPort had a mechanism, something like "did:uport::" that enabled references to other networks using the same method -- a part of the DID Method. AFAIK every DID method has multiple ledgers to use - mainly test instances of the primary net. However, we've talked of multiple production instances that share a DID method. Should there be a mechanism to enable that at the DID or DID Method level?

I'm guessing this has been discussed before, so the answer may be just a pointer to the docs that I've not found.

Thanks

did:kilt:5CDct4QDpQYfAVDrskNuiEdXyiE38oPfTHEJ65ZLSpz9WasE is not resolvable

Add Documentation for HTTP Proxy drivers

The documentation currently explains how to contribute a Driver in the form of a Docker container, but should also mention how to contribute a driver in the form of an HTTP Proxy (eg did:ipid, did:elem)

build failure

I tried forking this repo, then cloning to my MacBook and running cd universal-resolver/implementations/java/ followed by docker-compose -f docker-compose.yml build

The build fails (maven, java) with many errors, beginning with:
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ uni-resolver-driver-did-btcr ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /opt/uni-resolver-java/driver-did-btcr/src/main/resources
[INFO] skip non existing resourceDirectory /opt/uni-resolver-java/driver-did-btcr/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ uni-resolver-driver-did-btcr ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 5 source files to /opt/uni-resolver-java/driver-did-btcr/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /opt/uni-resolver-java/driver-did-btcr/src/main/java/uniresolver/driver/did/btcr/bitcoinconnection/BitcoinjSPVBitcoinConnection.java:[7,54] cannot find symbol
symbol: class Chain
location: class info.weboftrust.txrefconversion.TxrefConverter

Resolver error possibly JSON-LD related

https://element-did.com/api/v1/sidetree/did:elem:EiChaglAoJaBq7bGWp6bA5PAQKaOTzVHVXIlJqyQbljfmg

https://uniresolver.io/#did:elem:EiChaglAoJaBq7bGWp6bA5PAQKaOTzVHVXIlJqyQbljfmg

We have updated our context to an array to demonstrate an interop solution for extending contexts

Its possible that these values are causing errors:

https://docs.element-did.com/contexts/sidetree/sidetree-v0.1.jsonld

did:ipid:QmYA7p467t4BGgBL4NmyHtsXMoPrYH9b3kSG6dbgFYskJm is not resolvable

Create a cross-implementation JSON config

Per the related discussion, we should create a shared JSON config file that all implementations use, which should contain at least the following for each DID Method:

• 1 entry per DID Method prefix string
• Tag and version of matching driver image
• Test DID that can be run against the harness/CI
• Default environment variables used by the UR/Driver

Does not resolve DIDs with Query strings

example:

did:sov:WRfXPg8dantKVubE3HX8pw&chain=me

fails to resolve

The relevant documents on DID syntax are the DID spec itself
(W3C DID Spec)[https://w3c-ccg.github.io/did-spec/]
and the draft DID resolver specification
(W3C DID Resolution Spec)[https://w3c-ccg.github.io/did-resolution/]

By way of background. The original design of the DID syntax and semantics included the idea that a DID could include many of the features of a URL (URI, URN). These features included path, query, and fragment components. Initially only the fragment had a specific use case where a special type of fragment component was identified called a DID Fragment (not to be confused with a generic URL fragment). The query and path were overlooked. Later discussion and pull requests repaired that by including the query and path components as formal parts of the DID ABNF. However over time the spec has evolved and now the only place that query and path show up are in ABNF is the new DID URL representation. It appears this was done to simplify the DID service endpoint resolution algorithm but some important semantics may have been lost in the process. The only use case described by the specification is for a DID that includes path, query, or fragment components is in a DID URL that includes a matrix parameter "service". The DID path and query on the DID URL would then be appended to the service endpoint url. This is both good and bad. Good because the spec does not prevent us from adding additional semantics to the query and bad because the spec may not provide insufficient guidance to implementers. Importantly this may be problematic WRT the the current DID Resolution algorithm spec. My reading of the algorithm is that it is either ambiguous or incomplete and leaves undefined some edge cases. It may be simply that I am misreading the algorithm.

The relevant clauses from the DID spec follow:

did = "did:" method-name ":" method-specific-id
method-name = 1*method-char
method-char = %x61-7A / DIGIT
method-specific-id = *idchar *( ":" *idchar )
idchar = ALPHA / DIGIT / "." / "-" / ""
did-url = did ( ";" param ) path-abempty [ "?" query ]
[ "#" fragment ]
param = param-name [ "=" param-value ]
param-name = 1param-char
param-value = *param-char
param-char = ALPHA / DIGIT / "." / "-" / "" / ":" /
pct-encoded
"
4.5 Path
A generic DID path is identical to a URI path and MUST conform to the path-abempty ABNF rule in [RFC3986]. A DID path SHOULD be used to address resources available via a DID service endpoint. See Section § 5.6 Service Endpoints .
A specific DID scheme MAY specify ABNF rules for DID paths that are more restrictive than the generic rules in this section.

4.6 Query
A generic DID query is identical to a URI query and MUST conform to the query ABNF rule in [RFC3986]. A DID query SHOULD be used to address resources available via a DID service endpoint. See Section § 5.6 Service Endpoints .
A specific DID scheme MAY specify ABNF rules for DID queries that are more restrictive than the generic rules in this section.

4.7 Fragment
A generic DID fragment is identical to a URI fragment and MUST conform to the fragment ABNF rule in [RFC3986]. A DID fragment MUST be used only as a method-independent reference into the DID Document to identify a component of a DID Document (e.g. a unique key description). To resolve this reference, the complete DID URL including the DID fragment MUST be used as the value of the key for the target component in the DID Document object.
A specific DID scheme MAY specify ABNF rules for DID fragments that are more restrictive than the generic rules in this section.
It is desirable that we enable tree-based processing of DIDs that include DID fragments (which resolve directly within the DID document) to locate metadata contained directly in the DID document or the service resource given by the target URL without needing to rely on graph-based processing.
Implementations SHOULD NOT prevent the use of JSON pointers ([RFC6901]).
"
Note that for the DID path, query only should is applied for usage in a DID URL with a service endpoint. Other usages are allowed. The DID fragment uses MUST but the use case is not sufficiently well defined and should allow other use when not the defined use case.

Reverse lookup of semantic names

Should the UR support reverse lookup, e.g. find semantic names such as markus.id given a certain DID? This is not well understood yet and may only be possible with certain DID methods. This may also be out of scope for the UR but be implemented elsewhere.

Not able to canonize did doc

When trying to process json-ld returned by universal resolver for: did:btcr:xxcl-lzpq-q83a-0d5

const jsonld = require("jsonld");

const btrcDidDoc = require("./data/btcr-did-doc.json");

describe("test", () => {
  it("canonize", async () => {
    const canonized = await jsonld.canonize(btrcDidDoc, {
      format: "application/n-quads"
    });
    console.log(canonized);
  });
});

jsonld.ProcessingModeConflict: @version: 1.1 not compatible with json-ld-1.0

Error can be resolved by updating the did context:

 "@context": ["https://w3id.org/security/v2", "https://w3id.org/did/v1"],

Not sure what is going on here, but I would expect to be able to cannonize the result of resolve without modifying contexts.

did:stack method documentation

Documented the DID method for did:stack here: https://github.com/blockstack/blockstack-core/blob/master/docs/blockstack-did-spec.md

Failed to start docker image universalresolver/uni-resolver-web:latest

uni-resolver-web_1 | Downloading from central: https://repo.maven.apache.org/maven2/decentralized-identity/did-common-java/0.1.0/did-common-java-0.1.0.jar
uni-resolver-web_1 | [INFO] ------------------------------------------------------------------------
uni-resolver-web_1 | [INFO] BUILD FAILURE
uni-resolver-web_1 | [INFO] ------------------------------------------------------------------------
uni-resolver-web_1 | [INFO] Total time: 13.685 s
uni-resolver-web_1 | [INFO] Finished at: 2020-03-16T14:33:16Z
uni-resolver-web_1 | [INFO] ------------------------------------------------------------------------
uni-resolver-web_1 | [ERROR] Failed to execute goal on project uni-resolver-web: Could not resolve dependencies for project decentralized-identity:uni-resolver-web:war:0.2-SNAPSHOT: Could not find artifact decentralized-identity:did-common-java:jar:0.1.0 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
uni-resolver-web_1 | [ERROR]
uni-resolver-web_1 | [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
uni-resolver-web_1 | [ERROR] Re-run Maven using the -X switch to enable full debug logging.
uni-resolver-web_1 | [ERROR]
uni-resolver-web_1 | [ERROR] For more information about the errors and possible solutions, please read the following articles:
uni-resolver-web_1 | [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Cannot resolve did:web

Working:

https://uniresolver.io/1.0/identifiers/did:key:z6MksHh7qHWvybLg5QTPPdG2DgEjjduBDArV9EF9mRiRzMBN
https://uniresolver.io/1.0/identifiers/did:web:identity.foundation
https://identity.foundation/.well-known/did.json

Not Working:

https://uniresolver.io/1.0/identifiers/did:web:chapi.did.ai
https://chapi.did.ai/.well-known/did.json

Error:

Resolve problem for did:web:chapi.did.ai: DID document missing context

(not correct, bypassing the UR resolves the issue, and supports credential verification).

Is there an endpoint which does not process jsonld contexts yet? or a way to clear the cache of the resolver via http?

DID Protocol Version Support

Many DID Methods are currently under development or experimental...

Some use Blockchain Testnets, others use Mainnets.

I'd like to establish more clarity around how the universal resolver can support less stable DIDs in a way that does not create confusion or security issues.

One thought I had was to allow for simple resolver proxying, so that the universal resolver for "did:highly-experimental:123" might just call another http service which would be responsible for managing version changes.

This way we do not need to be publishing frequent changes to universal resolver for things that have not even stabilized yet.

Is this acceptable approach?

Spring Security DID-based Authentication Provider

We want to integrate DID-based authentication as an optional authentication method to our platform, which uses Spring Security.

For this, we plan to add a new authentication provider and integrate the Java-based did universal resolver.

Has anyone already started working on this? Any advice?

Resolve problem for did:btcr:xkrn-xzcr-qqlv-j6sl

When i am running the curl command

curl -X GET http://localhost:8080/1.0/identifiers/did:btcr:xkrn-xzcr-qqlv-j6sl

it's displaying this.

Resolve problem for did:btcr:xkrn-xzcr-qqlv-j6sl: Driver reported for did:btcr:xkrn-xzcr-qqlv-j6sl: Index: 0, Size: 0

Can anyone explain what does it mean?

How to set libindy path?

I have followed the documentation for universal resolver of resolver/java, I was able to build and run did:btcr but while working with did:sov driver. I need to set 'SetLibindyPath', 'SetPoolConfigurationName', 'setPoolGenesisTxn' .

i am trying to setup libindy path as follow:

uniResolver.getDriver(DidSovDriver.class).setLibIndyPath("/home/ankitshrivastava/universal-resolver/drivers/sov/sovrin");

But getting following error:

java.lang.UnsatisfiedLinkError: Unable to load library '/home/ankitshrivastava/universal-resolver/drivers/sov/sovrin': Native library (home/ankitshrivastava/universal-resolver/drivers/sov/sovrin) not found in resource path ([file:/home/ankitshrivastava/Documents/workspace-again/demo/target/classes/, file:/home/ankitshrivastava/universalResolver/universal-resolver/resolver/java/uni-resolver-client/target/classes/, file:/home/ankitshrivastava/universalResolver/universal-resolver/resolver/java/uni-resolver-core/target/classes/, file:/home/ankitshrivastava/universalResolver/did-common-java/target/classes/, file:/home/ankitshrivastava/.m2/repository/com/github/jsonld-java/jsonld-java/0.12.3/jsonld-java-0.12.3.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpclient-osgi/4.5.9/httpclient-osgi-4.5.9.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpmime/4.5.9/httpmime-4.5.9.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpclient-cache/4.5.9/httpclient-cache-4.5.9.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/fluent-hc/4.5.9/fluent-hc-4.5.9.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpcore-osgi/4.4.10/httpcore-osgi-4.4.10.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpcore-nio/4.4.12/httpcore-nio-4.4.12.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpclient/4.5.9/httpclient-4.5.9.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/httpcomponents/httpcore/4.4.12/httpcore-4.4.12.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-web/2.1.8.RELEASE/spring-boot-starter-web-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter/2.1.8.RELEASE/spring-boot-starter-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot/2.1.8.RELEASE/spring-boot-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-autoconfigure/2.1.8.RELEASE/spring-boot-autoconfigure-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-logging/2.1.8.RELEASE/spring-boot-starter-logging-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar, file:/home/ankitshrivastava/.m2/repository/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/logging/log4j/log4j-to-slf4j/2.11.2/log4j-to-slf4j-2.11.2.jar, file:/home/ankitshrivastava/.m2/repository/javax/annotation/javax.annotation-api/1.3.2/javax.annotation-api-1.3.2.jar, file:/home/ankitshrivastava/.m2/repository/org/yaml/snakeyaml/1.23/snakeyaml-1.23.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-json/2.1.8.RELEASE/spring-boot-starter-json-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.9.9.3/jackson-databind-2.9.9.3.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.9.0/jackson-annotations-2.9.0.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.9.9/jackson-core-2.9.9.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jdk8/2.9.9/jackson-datatype-jdk8-2.9.9.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.9.9/jackson-datatype-jsr310-2.9.9.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/jackson/module/jackson-module-parameter-names/2.9.9/jackson-module-parameter-names-2.9.9.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-tomcat/2.1.8.RELEASE/spring-boot-starter-tomcat-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/9.0.24/tomcat-embed-core-9.0.24.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/tomcat/embed/tomcat-embed-el/9.0.24/tomcat-embed-el-9.0.24.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/tomcat/embed/tomcat-embed-websocket/9.0.24/tomcat-embed-websocket-9.0.24.jar, file:/home/ankitshrivastava/.m2/repository/org/hibernate/validator/hibernate-validator/6.0.17.Final/hibernate-validator-6.0.17.Final.jar, file:/home/ankitshrivastava/.m2/repository/javax/validation/validation-api/2.0.1.Final/validation-api-2.0.1.Final.jar, file:/home/ankitshrivastava/.m2/repository/org/jboss/logging/jboss-logging/3.3.3.Final/jboss-logging-3.3.3.Final.jar, file:/home/ankitshrivastava/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-web/5.1.9.RELEASE/spring-web-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-beans/5.1.9.RELEASE/spring-beans-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-webmvc/5.1.9.RELEASE/spring-webmvc-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-aop/5.1.9.RELEASE/spring-aop-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-context/5.1.9.RELEASE/spring-context-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-expression/5.1.9.RELEASE/spring-expression-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-core/5.1.9.RELEASE/spring-core-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/spring-jcl/5.1.9.RELEASE/spring-jcl-5.1.9.RELEASE.jar, file:/home/ankitshrivastava/universalResolver/universal-resolver/resolver/java/uni-resolver-local/target/classes/, file:/home/ankitshrivastava/universalResolver/universal-resolver/resolver/java/driver/target/classes/, file:/home/ankitshrivastava/universalResolver/universal-resolver/resolver/java/driver-http/target/classes/, file:/home/ankitshrivastava/universalResolver/universal-resolver/drivers/sov/target/classes/, file:/home/ankitshrivastava/.m2/repository/com/google/code/gson/gson/2.8.5/gson-2.8.5.jar, file:/home/ankitshrivastava/universalResolver/universal-resolver/drivers/btcr/target/classes/, file:/home/ankitshrivastava/btc-tx-lookup-java/target/classes/, file:/home/ankitshrivastava/libtxref-java/target/classes/, file:/home/ankitshrivastava/libbech32-java/target/classes/, file:/home/ankitshrivastava/.m2/repository/wf/bitcoin/JavaBitcoindRpcClient/1.0.0/JavaBitcoindRpcClient-1.0.0.jar, file:/home/ankitshrivastava/.m2/repository/com/github/briandilley/jsonrpc4j/jsonrpc4j/1.5.3/jsonrpc4j-1.5.3.jar, file:/home/ankitshrivastava/.m2/repository/net/iharder/base64/2.3.9/base64-2.3.9.jar, file:/home/ankitshrivastava/.m2/repository/commons-io/commons-io/2.6/commons-io-2.6.jar, file:/home/ankitshrivastava/.m2/repository/org/bitcoinj/bitcoinj-core/0.15.2/bitcoinj-core-0.15.2.jar, file:/home/ankitshrivastava/.m2/repository/org/bouncycastle/bcprov-jdk15on/1.60/bcprov-jdk15on-1.60.jar, file:/home/ankitshrivastava/.m2/repository/com/google/protobuf/protobuf-java/3.6.1/protobuf-java-3.6.1.jar, file:/home/ankitshrivastava/.m2/repository/com/lambdaworks/scrypt/1.4.0/scrypt-1.4.0.jar, file:/home/ankitshrivastava/.m2/repository/com/google/guava/guava/27.0.1-android/guava-27.0.1-android.jar, file:/home/ankitshrivastava/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar, file:/home/ankitshrivastava/.m2/repository/com/google/guava/listenablefuture/9999.0-empty-to-avoid-conflict-with-guava/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar, file:/home/ankitshrivastava/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar, file:/home/ankitshrivastava/.m2/repository/org/checkerframework/checker-compat-qual/2.5.2/checker-compat-qual-2.5.2.jar, file:/home/ankitshrivastava/.m2/repository/com/google/errorprone/error_prone_annotations/2.2.0/error_prone_annotations-2.2.0.jar, file:/home/ankitshrivastava/.m2/repository/com/google/j2objc/j2objc-annotations/1.1/j2objc-annotations-1.1.jar, file:/home/ankitshrivastava/.m2/repository/org/codehaus/mojo/animal-sniffer-annotations/1.17/animal-sniffer-annotations-1.17.jar, file:/home/ankitshrivastava/.m2/repository/com/squareup/okhttp3/okhttp/3.12.1/okhttp-3.12.1.jar, file:/home/ankitshrivastava/.m2/repository/com/squareup/okio/okio/1.15.0/okio-1.15.0.jar, file:/home/ankitshrivastava/.m2/repository/net/jcip/jcip-annotations/1.0/jcip-annotations-1.0.jar, file:/home/ankitshrivastava/.m2/repository/commons-codec/commons-codec/1.11/commons-codec-1.11.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-actuator/2.1.8.RELEASE/spring-boot-starter-actuator-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-actuator-autoconfigure/2.1.8.RELEASE/spring-boot-actuator-autoconfigure-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-actuator/2.1.8.RELEASE/spring-boot-actuator-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/io/micrometer/micrometer-core/1.1.6/micrometer-core-1.1.6.jar, file:/home/ankitshrivastava/.m2/repository/org/hdrhistogram/HdrHistogram/2.1.9/HdrHistogram-2.1.9.jar, file:/home/ankitshrivastava/.m2/repository/org/latencyutils/LatencyUtils/2.0.3/LatencyUtils-2.0.3.jar, file:/home/ankitshrivastava/.m2/repository/org/springframework/boot/spring-boot-starter-log4j2/2.1.8.RELEASE/spring-boot-starter-log4j2-2.1.8.RELEASE.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.11.2/log4j-slf4j-impl-2.11.2.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.2/log4j-api-2.11.2.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.2/log4j-core-2.11.2.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/logging/log4j/log4j-jul/2.11.2/log4j-jul-2.11.2.jar, file:/home/ankitshrivastava/.m2/repository/org/slf4j/jul-to-slf4j/1.7.28/jul-to-slf4j-1.7.28.jar, file:/home/ankitshrivastava/.m2/repository/org/slf4j/slf4j-api/1.7.28/slf4j-api-1.7.28.jar, file:/home/ankitshrivastava/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.28/jcl-over-slf4j-1.7.28.jar, file:/home/ankitshrivastava/.m2/repository/org/slf4j/slf4j-log4j12/1.7.28/slf4j-log4j12-1.7.28.jar, file:/home/ankitshrivastava/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar, file:/home/ankitshrivastava/indy-sdk/wrappers/java/target/classes/, file:/home/ankitshrivastava/.m2/repository/net/java/dev/jna/jna/4.5.2/jna-4.5.2.jar, file:/home/ankitshrivastava/.m2/repository/org/apache/commons/commons-lang3/3.8.1/commons-lang3-3.8.1.jar, file:/home/ankitshrivastava/.m2/repository/org/json/json/20180130/json-20180130.jar])
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:303) ~[jna-4.5.2.jar:4.5.2 (b0)]
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:427) ~[jna-4.5.2.jar:4.5.2 (b0)]
at com.sun.jna.Library$Handler.(Library.java:179) ~[jna-4.5.2.jar:4.5.2 (b0)]
at com.sun.jna.Native.loadLibrary(Native.java:569) ~[jna-4.5.2.jar:4.5.2 (b0)]
at com.sun.jna.Native.loadLibrary(Native.java:544) ~[jna-4.5.2.jar:4.5.2 (b0)]
at org.hyperledger.indy.sdk.LibIndy.init(LibIndy.java:242) ~[classes/:na]
at uniresolver.driver.did.sov.DidSovDriver.openIndy(DidSovDriver.java:282) ~[classes/:na]
at uniresolver.driver.did.sov.DidSovDriver.resolve(DidSovDriver.java:131) ~[classes/:na]
at uniresolver.local.LocalUniResolver.resolve(LocalUniResolver.java:119) ~[classes/:na]
at uniresolver.local.LocalUniResolver.resolve(LocalUniResolver.java:49) ~[classes/:na]
at com.example.demo.service.ResolverService.getDocumentSov(ResolverService.java:153) ~[classes/:na]
at com.example.demo.controller.HomeController.helloagain1(HomeController.java:44) ~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_222]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_222]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_222]

Add trustbloc driver

https://github.com/trustbloc/trustbloc-did-method/blob/master/docs/spec/trustbloc-did-method.md

Consider Security Quick Scan

I have been contacted via e-mail by Radically Open Security. They will conduct a basic security quickscan of this project. I will follow up here in this issue once this is done and more information is available.

Error when running docker-compose (with latest docker version)

When following the quick start steps (https://github.com/decentralized-identity/universal-resolver#quick-start):

docker-compose -f docker-compose.yml pull returns the following error:
"In file ./.env: environment variable name 'ENV uniresolver_driver_did_erc725_etherscanApis' may not contains whitespace."

Note: if you're reading this and want to fix this issue temporarily and locally, you might want to remove ENV on line 12 of the .env file.

Need to update config.json for did:btcr

As we have seen earlier (#40) did:btcr are following 4-4-4-3 or 4-4-4-2 pattern and not 4-4-4-4 pattern. So we need to update the

testIdentifiers of did:btcr driver in config.json.

Document method/driver registration requirements

Basic requirements for registering new DID methods are defined in the DID spec, e.g. see w3c-ccg/did-method-registry#5 and w3c-ccg/did-method-registry#6

Communities such as DIF may specify DID implementer guidelines that extend the baseline W3C requirements, e.g. see https://docs.google.com/document/d/1wB0hHqgWbwdj5axo0FteVivEnJE5_TzXeRsfJPntKQ0/

The UR should document its driver governance, i.e. how new drivers can be added to a "default" configuration.