Hi @BenchToMarket, you can find our deployed contract here.
If you inspect any transaction sent to it (example), and view the
Input Data as
UTF-8, you'll see something along the lines of:
Zµî73>uÊnwOepiN\ýú9¢ªdjî»°ö§´@.QmQiLVrYjtH1nATYdXzEun2JeZnTLt6nXD7Ed2hZhaqCRJ. (The first section is of type
The IPFS hash anchored in this transaction is
You can then query any public ipfs gateway, for instance:
to get the DID Document
Along with above: how can i view my did on Rinkeby Etherscan? ~is there 1 did for me AND 1 for every credential?
Each agent (e.g. user, service, device) has a
did. Credentials contain the
did of the issuer and subject, but are not themselves assigned
Hi. Analogous to @BenchToMarket question, I'd like to know the steps the EthereumConnector and IPFSConnecter takes how to create an identity and anchoring it to the Ethereum Chain und IPFS.
I wrote some Custom Connector for both (Ethereum and IPFS), which just implements the default connectors. I run some console.log() to see, which function gets called why and when. For example, after I call the registry.create(vaultedKeyProvider, password) function to create a new IdentityWallet, I get this output:
Intercepted request for did:jolo:.... -> (which return some 46-length string like 'QmYb...'
Intercepted catJSON IPFS
Intercepted storeJSON IPFS
Intercepted request for did:jolo:... , updating to QmYb...
My question is, what does the 'resolveDID(...)' function excatly do, when it returns a string like 'QmYb...' etc? What is stored on the Ethereum-Blockchain? It is a key-value pair like did:jolo -> QmBy...?
In case of resolving a did:
Calling resolveDID on Ethereum Resolver which calls the getRecord method on the identity contract with the DID as an argument to get back the IPFS hash,
Call catJSON on the IPFS connector with the IPFS hash as an argument to get the associated DID document.
Pasting an answer I gave some days back in our Telegram channel for a bit of context on the custom connector stuff:
Eugeniu admin, [16. Apr 2019 at 11:26:11 (16.04.19, 11:26:25)]:
...We are currently integrating the wallet / lib with some custom deployments as well, and it's becoming apparent that the abstractions put in place when the lib was written, although sufficient for now, are a bit restrictive.
We will be spending some time next sprints looking at how the components (e.g. registry, storage, contracts support) can be abstracted further, in a more natural way. (E.g. currently there's no reason the ipfsConnector should be specific to ipfs in any way, and some bits of the interface [e.g. requiring the "pin" arg on the storeJSON, which is an implementation detail] should be updated).
Ideally actually making use of the abstractions will highlight inconsistencies / redundancies in our model, which we can address in further releases.
As an FYI -- Jolocom, through DWeb Berlin, will be hosting events all week from our Betahaus Kreuzberg location:
15 May >> For your designers... Berlin Typonight : http://bit.ly/typonight
18 May >> Identity for NPEs (from an SSI lens) with @heathervescent : http://bit.ly/StammtischwHeather
20 May >> Jolocom's 5th birthday party :tada: : http://bit.ly/jolocomis5
And for those of you at BCX/BCW this week, we'll be there. Let me know if you're looking to connect in person.
Hey @/all ,
A quick announcement for those looking to demo our protocol and libraries:
Start with the Municipal Service to load up on some demo credentials. Then visit our University Service to begin the application process as a prospective student...or head straight to the pool instead, and get a discount on entry using our Swimming Pool Service.
This guide provides a technical overview of these new demo services, plus links to documentation and developer resources.
You can also refer to this video guide for the full user story and a walkthrough covering each of the above services.
@huidwd2 Maybe I misunderstood your question. Let me try to clarify:
When opening the SmartWallet for the first time, all users are taken through an initial set up that involves creating & registering a DID (i.e. SmartWallet users provision a DID to themselves during the initial application setup).
Currently, there is no UI element in the app that displays the actual DID (string) created — which is what I understood to be your question.
But even without being able to see the actual DID, a SmartWallet user can “connect” to any service that supports a simple DID authentication interaction using the DID created during application setup.
@blazedarwin No, you understood my point :-) I only wanted to see my own DID, thats all. It would be nice of you could add this feature in the future :-)
What i meant with "connect to services" was that you can add your DID to some kind of account of a various service, to "enable" a login with jolocom
Hi. Got a little problem here, maybe you could help me:
I've been trying to verify a signed credential with my own did, like shown in the docs:
const providedCredentials = cResponse.suppliedCredentials
const seed = Buffer.from(/mySeedHere/, 'hex')
console.log(await JolocomLib.keyProvider.verifyDigestable(seed, providedCredentials ))
Unfortuneatly, I run into this error -> (node:24628) UnhandledPromiseRejectionWarning: TypeError: Expected Point
My signedCredetial is of type SignedCredential
In case you missed it, our engineers released one of the biggest updates to date of the Jolocom library and SmartWallet. Take a look at the release notes on github here >> https://github.com/jolocom/smartwallet-app/releases/tag/v1.6.0
Read more on it, and check out the demos >> https://app.mailerlite.com/l7i5s7
verifyDigestableis taking the publicKey and the digestible as parameters. In your code example it looks like you are using your seed instead of the publicKey. You can generate the publickey based on a seed with the help of the
SoftwareKeyProvider. Let us know if this solves your problem.
jolocom-libas an npm module at the moment and would like to access some other classes like
SoftwareKeyProvideretc. Does anyone know if this is possible with the library in its current form? Great work by the way, really impressed with how super tidy the code is
In case you're curious >> a quick technical explainer from Kai Wagner and Joerg Rueckrieman on how we built our SSI tech into the Xride scooter rideshare system >> https://youtu.be/xuMojUAf6xg
A full recap from the launch event we attended last week at the Deutsche Telekom Headquarters in Bonn can be found here >> https://medium.com/@Jolocom/decentralized-ride-sharing-launches-in-bonn-3c0cf0cc3795
And that's a wrap! 🎬 We've had a fantastic 2019 and cannot wait for the new pilots, projects, and real world application for #selfsovereignidentity solutions that 2020 will bring 🎉
Learn about what we achieved this year and how far we've come in our Year in Review blog post — everything from new product specs to new projects in #mobility and #egovernment. Our team has grown, we've been around the world in events, joined new communities and are extremely pleased to have had a chance to work with so many great companies and communities.
Read more in our recap here: