Come here to report bugs or ask questions about the Jolocom SmartWallet and underlying protocol
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
verifyDigestable is 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-lib as an npm module at the moment and would like to access some other classes like Identity, SoftwareKeyProvider etc. 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:
https://stories.jolocom.com/jolocom-2019-year-in-review-7404cec5b47a
Our update for January now available: https://app.mailerlite.com/s7u5l1
As always let us know if you need support or questions answered on our code 👍🏽
hi, im trying to make your generic-backend run under Ubuntu
and also to make an APK Package in Android Studio under Ubuntu of your jolocom wallet for testing purposes. It might be a starters question,
but may be you can help me, since i have some issues with those tasks.
Concerning the APK: I got the Source of Github and when prompted i created an Android Studio Project for it.
Then following Onscreen instructions which left me with 3 directories named: androidTest, debug, and main
Is that a working valid way to do it or do i have to do it otherwise to get it to work,
because the package wont get done with an Error referring to: appcompat.theme(missing library?) or am i completely wrong here?
Referring to the generic backend or in general: should i use node version 10.15 or is a higher version also fine to work with?
Can you clarify a couple things?
- What do you mean by "Frontend" and how is it different from the "Backend"? In context of our usual flows, there's a nodejs backend that also serves a simple HTML/JS frontend (which sometimes talks to the backend over WebSockets but can also just do normal http)
- What are you assuming wouldn't work in local dev envs?
- There's a bit of a security issue if your frontend and backend are not served by the same server
- You have to authorize the frontend to the backend, or in some way verify that only authorized frontends can create QR codes (which are just a means to transport
interaction tokens) and pass them on to the wallet. - Optimally the wallet should never callback into a "frontend", always directly contacting the backend
- You have to authorize the frontend to the backend, or in some way verify that only authorized frontends can create QR codes (which are just a means to transport
- You do need some identity-capable entity of course to be able to do any interactions
- The
generic-backendis not necessary as a middleman. Any service that you already run (using nodejs of course, since we don't yet have bindings for other languages....) can maintain and use its own identity.- Do you have your own service that you are trying to authenticate/login users into? The wallet should talk to it directly (via the right
callbackUrlin theinteraction tokens) - Your service can then issue interaction tokens (as QR codes) directly, and it can do the
generic-backend's job- this basically means using the
generic-backendas a template to start your project from, and adding your own use-case specific code in there - at some point we are going to release an
expressjsplugin for easy SSI integration, instead of distributing thegeneric-backend - If you already have your own services and you still want to use a separate backend (the
generic-backend) to manage SSI interactions, then make sure you create trusted and secure connections between your services and thegeneric-backend!
- this basically means using the
- Do you have your own service that you are trying to authenticate/login users into? The wallet should talk to it directly (via the right
@iwTGBs: that i firstly get back an QR Code from the backend and eventually but not necessarily, [...], authenticate via the QR Code in the confined spaces of my local development network?
Not sure if this is clear but:
To "authenticate via the QR code" the wallet will actually send HTTP requests to the backend that issued the interaction token that is encoded in this QR code, so you absolutely need the wallet to have access to the backend
SoftwareKeyProvider {
encryptedSeed:
<Buffer 78 9e 02 4e 4a 3f d4 44 f4 50 a1 1c 97 9d 3a 86 c1 8c c7 d4 62 a0 3e 58 11 f7 8e fe 10 c3 20 c4 ee 04 71 61 a6 e2 08 1b 1c 0f 1c 00 70 3c 42 54> }
(node:17865) UnhandledPromiseRejectionWarning: Error: Could not retrieve DID Document. Returned error: project ID is required
at JolocomRegistry.<anonymous> (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:172:31)
at step (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:32:23)
at Object.throw (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:13:53)
at rejected (/home/johannes/Desktop/generic-backend/node_modules/jolocom-lib/js/registries/jolocomRegistry.js:5:65)
at process._tickCallback (internal/process/next_tick.js:68:7)
(node:17865) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:17865) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. What can i do about that?
Hi @iwTGBs, this is caused by that branch using an older version of the library which uses a since-deprecated Infura API. To solve, I would recommend either using the master branch of the generic backend or upgrading your jolocom-lib dependency to 4.0.1. The master branch should still work for the swimming pool as long as you keep the same config.ts file, however some type definitions may have changed slightly, e.g.:
/* Credentials required during authentication */
export const currentCredentialRequirements = ['a-kaart']
export const credentialRequirements = {
'a-kaart': {
metadata: demoClaimsMetadata.akaart
}
} as { [key: string]: ICredentialReqSection }
/* Credentials offered by the service. */
export const credentialOffers = {} as {
[key: string]: {
schema: BaseMetadata
metadata: {
renderInfo?: CredentialOfferRenderInfo
metadata?: CredentialOfferMetadata
}
}
}The main changes on the aKaartIntegration branch are related to integration with an external service via adding custom middleware, so it is still a good example of that.
I think a more plausible solution would be to merge master into into it to get it up to date, if you really insist on using it
though a much better solution is as @chunningham outlined in https://gitter.im/jolocom/SmartWallet?at=5e56488cd7bb4e179ca1b614
We're on rinkeby network. You can find that information in the jolocom registry code: https://github.com/jolocom/jolo-did-method/blob/master/jolo-did-registry/ts/index.ts
Which flow are you implementing?
CredentialSharemanaged by https://github.com/jolocom/generic-backend/blob/master/src/controllers/registration.ts- or
CredentialOffermanaged by https://github.com/jolocom/generic-backend/blob/master/src/controllers/issuance.ts
await setStatusDone(redis, nonce)
which will send data through the
socket, and I think that's what you are missing!
watchDbForUpdate is for)
export const currentCredentialRequirements = ['email']. i assume thats the setting if an /authenticate/ get request comes in. wallet scans code and sends email to backend for pass to frontend . is that CredentialShare or CredentialOffer.
You must do that manually if you want/need to.
The backend will only send a success message over the websocket