Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mina Nagy Zaki
    @mnzaki
    More complete documentation (with hopefully less misleading diagrams :D) will also be coming up soon!
    But first we want to get out a solid usage example!
    1 reply
    Chinmay Patel
    @ChinmayPatel
    Thanks @mnzaki for brining me here.
    Mina Nagy Zaki
    @mnzaki
    Welcome!
    Chinmay Patel
    @ChinmayPatel
    Is the current documentation at https://jolocom-lib.readthedocs.io/en/latest/introduction.html compatible with the latest SDK & demos?
    3 replies
    I'm just trying to ensure that I don't run into any compatibility issues.
    Chinmay Patel
    @ChinmayPatel
    I've been playing with the jolocom-cli and running into some errors. I've submitted two issues at jolocom/jolocom-cli#19 & jolocom/jolocom-cli#20. Who should be the best person to chat with?
    Mina Nagy Zaki
    @mnzaki
    @ChinmayPatel Thanks for the github issues, we can discuss further there!
    jolocom-cli is outdated and currently not being maintained due to other priorities
    Mina Nagy Zaki
    @mnzaki
    @ChinmayPatel There were a few issues, I took some time to publish a new version of the CLI, 1.9.2, which I think should work for you!
    Chinmay Patel
    @ChinmayPatel
    @mnzaki thank you very much. I'll try it today.
    Chinmay Patel
    @ChinmayPatel
    HI @mnzaki , I have submitted one more issue at jolocom/jolocom-cli#21. Can you please take a look at it
    3 replies
    ?
    Shekhar-Pathak
    @Shekhar-Pathak
    Hi @mnzaki, further to our communication, could you please let us know why SDK is not yet production ready?
    Shekhar-Pathak
    @Shekhar-Pathak
    Any input on above, please?
    Julian Dreissig
    @thirtified
    Hi Jolocom team, we have noticed that there are v5.1 release candidates for the jolocom-lib available on npm but not yet on GitHub. When do you plan to make the sources available? Thanks
    1 reply
    thomasmodeneis
    @thomasmodeneis
    hello everyone
    I am trying to setup a complete stack with the bare minimum I need to use jolocom with Smilo blockchain
    I cloned the jolo-did-method, compiled it all, configured the truffle to deploy the smart contract to the smilo blockchain
    then I cloned a old repo, demo-sso and now I am facing a issue that seems to be related to this
    registry.authenticate(vaultedKeyProvider, {derivationPath: JolocomLib.KeyTypes.jolocomIdentityKey, encryptionPass: password}) .then(identityWallet => { configureRoutes(app, {setAsync, getAsync, delAsync}, identityWallet, password) configureSockets(server, identityWallet, password, new DbWatcher(getAsync), {getAsync, setAsync, delAsync}) })
    it throws:
    Demo service started, listening on port 9010 (node:329398) UnhandledPromiseRejectionWarning: Error: Could not retrieve DID Document. Returned error: project ID is required at JolocomRegistry.resolve (/opt/js/jolocom/demo-sso/node_modules/jolocom-lib/ts/registries/jolocomRegistry.ts:175:13) at process._tickCallback (internal/process/next_tick.js:68:7) (node:329398) 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:329398) [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.
    I think that is because I am missing Where is your service deployed. E.g. https://demo-sso.jolocom.com
    my question is, what is the service I have to have running local to pass over this err ?
    is the generic backend ?
    thomasmodeneis
    @thomasmodeneis
    anyone here ?
    chunningham
    @chunningham
    Hi @thomasmodeneis , apologies for the wait. You are correct that the generic backend would be the service to be running locally, however both Demo-SSO and the generic backend are out of date at this state. instead I would recomment to look at this dockerised example application: https://github.com/jolocom/interactions-demo
    The difference is that we have moved to using our SDK for almost all services and use cases
    existing work you have done to integrate your new DID method can be transferred to the SDK by implementing it similarly to the jolocom DID method here: https://github.com/jolocom/jolocom-lib/blob/next/ts/didMethods/jolo/index.ts (basically implementing the IResolver, IRegistrar interfaces)
    harshitg9715
    @harshitg9715
    Hi all, I raised an issue on the jolocom generic backend, I resolved the issue. It was created because the jolocom wallet application (which i built using sdk) was generating did as did:juan:... and which were not being resolved by backend, everything worked fine with the official app on android play store. I cannot close the issue since the repo is archived.
    chunningham
    @chunningham
    hi @harshitg9715, the Generic Backend relies on a now-outdated version of the library. did:jun is a new DID method we have developed which works in a fully peer-to-peer way (without relying on a blockchain) and it is the new default for the smartwallet. The SDK provides built in support for both did:jun and did:jolo, however older versions of our tools do not support it. We recommend the SDK for building applications and services for this reason. A version of the wallet built on the SDK will be released publically in the coming days (already available on ios testflight and the android beta program)
    thomasmodeneis
    @thomasmodeneis
    hi @chunningham I appreciate your answer, but I still want to make this work with a blockchain and using that demo was the idea.
    8 replies
    could you answer what is required there so I can move forward ?
    harshitg9715
    @harshitg9715
    hi @chunningham , Thankyou for the clarification. The new documentation is great! I am going through the new docs now. However, it does not cover creation of public profile as of now. I was hoping if you could assist me with that. I was successful in creating an agent instance on jolo and a respective document that could be resolved on uniresolver.io.
    chunningham
    @chunningham
    the new impl of the jolocom DID method has a method for updating the profile. for accessing via the sdk, you can use sdk.didMethods.get('jolo').registrar.updatePublicProfile
    you will need to // @ts-ignore that line, the .didMethods object will not show the full type
    ganeshyedla
    @ganeshyedla
    Hi @chunningham , we were able to create public profile, request and issue credentials using the generic backend but as it relies on the deprecated version of the library, we wanted to replicate the same with the new SDK but were unable to create a public profile as the docs doesnt cover this section. Can you please suggest the steps to setup an Identity with a public profile with the new SDK.
    harshitg9715
    @harshitg9715

    Hi @chunningham , In the creating an Identity section of the documentation, the sdk.createNewAgent method for creating agent with a new random identity does not exists in the SDK.

    I assumed it must me sdk.createAgent , but upon calling this one I am getting the error: insufficient funds for intrinsic transaction cost, Is there some initial SDK configuration that I am missing ? can you please clarify this.

    also, the example in the same section of docs mention loadIdentity method, which again does not exists in sdk.

    harshitg9715
    @harshitg9715
    Hi all, I was hoping if someone can point me in the right direction here.
    some minor updates:
    • I was able to successfully create a public profile.
    • I am unable to fetch the did of my agent on universal resolver
    • I am unable to create any new agents or update the created profile again, getting INSUFFICIENT_FUNDS error.
    • I even tried to fuel the registryContractAddress, but that failed as well.
    chunningham
    @chunningham
    Hey @harshitg9715, sorry about that, the free fueling service we provide has run out of ether. this has become an issue since our did method has become more popular and the official rinkeby faucet has become less reliable
    harshitg9715
    @harshitg9715
    @chunningham, Thankyou for the update. do you think there is an alternative in place that I can go ahead and use right now?
    chunningham
    @chunningham

    you can extract the eth public key using this line:

    const {publicKeyHex} = await agent.keyProvider.getPubKeyByController(password, `${keyProvider.id}#keys-2`)

    if you prepend 0x to publicKeyHex you have the eth address and can fuel it here: https://faucet.rinkeby.io/

    harshitg9715
    @harshitg9715

    Hi @chunningham , fueling did work, but i still cannot create an agent, I think there is some restrictions on infura API that is configured in the sdk. here is the new error generated by await sdk.createAgentFromMnemonic(mnemonic) :

    {
      reason: 'bad response',
      code: 'SERVER_ERROR',
      status: 403,
      headers: {
        date: 'Wed, 25 Nov 2020 10:16:32 GMT',
        'content-type': 'application/json',
        'content-length': '97',
        connection: 'close',
        vary: 'Origin'
      },
      body: '{"jsonrpc":"2.0","id":48,"error":{"code":-32002,"message":"rejected due to project ID settings"}}',
      requestBody: '{"method":"eth_getTransactionReceipt","params":["0xf01c2e205f069579ae03ec16324b159c69828ac8639ab81f6972976d8fcea7f9"],"id":48,"jsonrpc":"2.0"}',
      requestMethod: 'POST',
      url: 'https://rinkeby.infura.io/v3/64fa85ca0b28483ea90919a83630d5d8'
    }

    Do I need to configure my own infura API?

    1 reply
    ganeshyedla
    @ganeshyedla
    Hi @chunningham , @clauxx , tried running interactions-demo based on the new SDK in my local, was able to run frontend and the service agent, one thing we couldnt understand was how do you update the web-frontend that the interaction actually succeeded like in Authentication interaction how do you make the shared credential (email) available to the web-frontend? It was apparent in generic-backend that an identifier for the JWT token was being stored as a key-value pair in the redis db along with the status of the interaction. Can you please tell how is it being done here in the interactions-demo based on the new SDK and how do you make use of the shared credentials using the new SDK because the Jolocom SDk docs doesnt cover it.
    3 replies
    ganeshyedla
    @ganeshyedla
    Hi @mnzaki, we are looking into a usecase of pushing the credential to the wallet instead of asking the user to scan again to receive a credential to make it as straight forward as possible. The flow is => user scans a qr code at the login and shares his self-signed email which will be verified by an OTP , on a successfull OTP verification we want to push a signed credential to the wallet instead of asking user to scan another qr code to receive that credential. We are already using websockets with server and webclient. Is it configurable at the Wallet side to have a websocket connection with the server, so that the server can push the credential to the walllet ? . We understand it could raise potential security issues but please suggest us how we can approach this usecase. Thanks!
    2 replies
    Stefan Adolf
    @elmariachi111
    Aloha, good people. Jumped into your SDK & smart wallet code again and I think it, it has quite advanced since the last time I gave it a try ;). So atm I'm able to create agents & identities on my local machine, successfully do the authentication and credential offer flows with the Jolocom Smart Wallet & a plain https service I deployed somewhere but now I'm stuck when presenting the real credential to the app user. The React app tells me on my Android phone the it can't read the QR code containing the JWT I created with createCredentialReceiveToken. According to the app's sources the error message ("Is this the right QR code?") doesn't seem to be related to any semantic issue but rather to the scanning component itself...
    2 replies
    ganeshyedla
    @ganeshyedla
    Hey @mnzaki, I am facing an issue with recovering identities in the Jolocom smart wallet. Backed up my identity and stored my seed phrase before receiving any credentials and gone through Avalon Demo to receive few credentials to the wallet. Then uninstalled and reinstalled the app to test the Identity recovery, the seed phrase succeeds but the wallet doesnt show any previously acquired credentials one would expect in a recovery mechanism. Basically the wallet is empty. Please suggest me If i am doing something wrong or is it an issue with the wallet.
    6 replies
    Stefan Adolf
    @elmariachi111

    Hey @mnzaki. I just tried to issue a credential using the SDK (agent.signedCredential) and its result looks somewhat like that:

    {
      "@context": [{... }],
      "id": "claimId:7ec6727ad99da462",
      "issuer": "did:jun:EIhOKjlnpnEsHudHj84PRlWiMsMha1vd69kif6q51yIs",
      "issued": "2021-03-04T10:40:43.245Z",
      "type": [
        "VerifiableCredential"
      ],
      "expires": "2022-03-04T10:40:43.243Z",
      "proof": {
        "created": "2021-03-04T10:40:43.245Z",
        "type": "EcdsaKoblitzSignature2016",
        "nonce": "a51c16c7d7cdb0a6",
        "signatureValue": "bf5ef5ade74d87203e677c2d315ed39268efcafd1430d755714489167a7ef035b96a3748cbbf7810292e47692898c0951977bf1bebfc3bdf59154b800f7af70b",
        "creator": "did:jun:EIhOKjlnpnEsHudHj84PRlWiMsMha1vd69kif6q51yIs#DmMZ5ie0zfSNyFwjVf1oUKIVwwOXRfwze1uIJ7T44La8"
      },
      "claim": {
        "provider": {
          "type": "ImmunizationProvider",
          "name": "John Doe"
        },
        "id": "did:key:z6MkuSH7TFfdcGSBLriB5jAjfqKbbWf1C3qPhqJwSJTqdWL8"
      },
      "name": "VerifiableCredential"
    }

    got these questions:

    BTW: I think these people did a great job putting the specs into typed code. Any chance that you might integrate these types into jolocom-lib at anytime? Would help interoperability for sure ;)

    • I found that the sdk can store many dids at once (loadable by the agent interface) but haven't found an API to iterate them / look them up. So, while I always could agent.createNewIdentity I never can agent.listIdenities. Any reason for that?
    5 replies
    Stefan Adolf
    @elmariachi111

    Ok, giving up after wrapping my head for too long around JSON-LD and custom (nested) credentials. I have a (nested) claim that looks like this:

    {
      "provider": {
        "type": "ImmunizationProvider",
        "name": "John Doe"
      }
    }

    instead like that:

      {
        "email": "foo@bar"
      }

    Since you're relying on JSON-LD verification / RDF normalization under the hood, I'm supposed to send metadata describing the schema along. My current try is:

     const metadata = {
      fieldNames: ['provider'],
      optionalFieldNames: [],
      type: "ProofOfProviderCredential",
      name: "proofs you're a provider",
      claimInterface: {
        provider: {
          type: "",
          name: "",
        }
      },
      context: [{
        ProofOfProvider: "https://example.com/terms/ProofOfProviderCredential", 
        schema: "https://schema.org",
        provider: "schema:person"
      }]
    }
    
    const signedCredential = await agent.signedCredential({
      metadata,
      subject: <some-did>,
      claim: {
        provider: {
          type: "ImmunizationProvider",
          name: "John Doe",
        }
      }
    })

    and the result looks like

    {
      "@context": [
        {
          "id": "@id",
          "type": "@type",
          "cred": "https://w3id.org/credentials#",
          "schema": "http://schema.org/",
          "dc": "http://purl.org/dc/terms/",
          "xsd": "http://www.w3.org/2001/XMLSchema#",
          "sec": "https://w3id.org/security#",
          "Credential": "cred:Credential",
      ... ... ...
        },
        {
          "ProofOfProvider": "https://example.com/terms/ProofOfProviderCredential",
          "schema": "http://schema.org/",
          "provider": {
            "@id": "schema:person",
            "@type": "@id"
          }
        }
      ],
      "id": "claimId:d2a711b3a6655906",
      "issuer": "did:jun:ESgcd47lYOODgJQ4WUP1kVyP1BpeanZfhFvI0sIrYN6w",
      "issued": "2021-03-23T18:30:11.628Z",
      "type": [
        "VerifiableCredential",
        "ProofOfProvider"
      ],
      "expires": "2022-03-23T18:30:11.626Z",
      "proof": {
        "created": "2021-03-23T18:30:11.628Z",
        "type": "EcdsaKoblitzSignature2016",
        "nonce": "b11c28c28fd64364",
        "signatureValue": "f845caa9ff61d36238979fede170a0dea48699fc53a9cf16c0f026ed3bf25047036e211a113697f0d51b45c99bccea1edd7c61314e5e35dfdfbc4e6b1c402201",
        "creator": "did:jun:ESgcd47lYOODgJQ4WUP1kVyP1BpeanZfhFvI0sIrYN6w#Djg_ceBWaXIy7JdiO-HfQK-wVaF2u0OMDr5yIARfDCJM"
      },
      "claim": {
        "provider": {
          "type": "ImmunizationProvider",
          "name": "John Doe"
        },
        "id": "did:key:z6MkuSH7TFfdcGSBLriB5jAjfqKbbWf1C3qPhqJwSJTqdWL8"
      },
      "name": "VerifiableCredential,ProofOfProvider"
    }

    the normalization isn't working here: When I change the claim's key property name (provider => proVider), the verification fails. If I change anything inside the provider object, it verifies fine (the signature isn't taking these fields into account).

    Question:

    How do I define a schema that allows this kind of nested claims? (there'll be much more nesting going on in the real case, btw, similar to: https://github.com/smart-on-fhir/health-cards-tests/blob/master/src/fixtures/vc-covid-immunization.json)

    btw, when using https://w3id.org/credentials/v1 in the schema, the agent throws jsonld.ProcessingModeConflict: @version: 1.1 not compatible with json-ld-1.0 but I guess that's due to an outdated dependency under the hood.

    1 reply
    emixdemix
    @emixdemix
    Hello all, I would like to know if there is some kind of standards to send and request VCs so that the processes to request, verify, offer are interoperable with other vendors. Jolocom SDK uses the "callback_url" method to achieve that, however other vendors'app do not "understand" that and they use their own way to dispatch VC around. Is there anything already, or is this topic already solved and standardized?
    Thanks!
    3 replies
    emixdemix
    @emixdemix
    Hello @mnzaki I am facing an issue on my app when accepting an offer, while inserting into VerifiableCredentials throws an error saying sqlite FK not valid. The token is the following eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NksifQ.eyJpbnRlcmFjdGlvblRva2VuIjp7InNpZ25lZENyZWRlbnRpYWxzIjpbeyJAY29udGV4dCI6W3siaWQiOiJAaWQiLCJ0eXBlIjoiQHR5cGUiLCJjcmVkIjoiaHR0cHM6Ly93M2lkLm9yZy9jcmVkZW50aWFscyMiLCJzY2hlbWEiOiJodHRwOi8vc2NoZW1hLm9yZy8iLCJkYyI6Imh0dHA6Ly9wdXJsLm9yZy9kYy90ZXJtcy8iLCJ4c2QiOiJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSMiLCJzZWMiOiJodHRwczovL3czaWQub3JnL3NlY3VyaXR5IyIsIkNyZWRlbnRpYWwiOiJjcmVkOkNyZWRlbnRpYWwiLCJpc3N1ZXIiOnsiQGlkIjoiY3JlZDppc3N1ZXIiLCJAdHlwZSI6IkBpZCJ9LCJpc3N1ZWQiOnsiQGlkIjoiY3JlZDppc3N1ZWQiLCJAdHlwZSI6InhzZDpkYXRlVGltZSJ9LCJjbGFpbSI6eyJAaWQiOiJjcmVkOmNsYWltIiwiQHR5cGUiOiJAaWQifSwiY3JlZGVudGlhbCI6eyJAaWQiOiJjcmVkOmNyZWRlbnRpYWwiLCJAdHlwZSI6IkBpZCJ9LCJleHBpcmVzIjp7IkBpZCI6InNlYzpleHBpcmF0aW9uIiwiQHR5cGUiOiJ4c2Q6ZGF0ZVRpbWUifSwicHJvb2YiOnsiQGlkIjoic2VjOnByb29mIiwiQHR5cGUiOiJAaWQifSwiRWNkc2FLb2JsaXR6U2lnbmF0dXJlMjAxNiI6InNlYzpFY2RzYUtvYmxpdHpTaWduYXR1cmUyMDE2IiwiY3JlYXRlZCI6eyJAaWQiOiJkYzpjcmVhdGVkIiwiQHR5cGUiOiJ4c2Q6ZGF0ZVRpbWUifSwiY3JlYXRvciI6eyJAaWQiOiJkYzpjcmVhdG9yIiwiQHR5cGUiOiJAaWQifSwiZG9tYWluIjoic2VjOmRvbWFpbiIsIm5vbmNlIjoic2VjOm5vbmNlIiwic2lnbmF0dXJlVmFsdWUiOiJzZWM6c2lnbmF0dXJlVmFsdWUifSx7InNjaGVtYSI6Imh0dHBzOi8vc2NoZW1hLm9yZy8iLCJlbWFpbCI6InNjaGVtYTplbWFpbCJ9XSwiaWQiOiJjbGFpbUlkOjY5NmY5Zjc2YzhiOWJlM2EiLCJpc3N1ZXIiOiJkaWQ6am9sbzo2NDEyZWQ2ODUyYmMyY2YwYWNkZTNlNTFkZWJiOGUzY2M5OGM4MzgzYTZmMjlkNzQ1MzVlOTcyMmRkMjZmZGI2IiwiaXNzdWVkIjoiMjAyMS0wNC0xNFQwOToyMjoyNS42NTJaIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkV0b25lY0VtYWlsT2ZmZXIiXSwiZXhwaXJlcyI6IjIwMjItMDQtMTRUMDk6MjI6MjUuNjQ3WiIsInByb29mIjp7ImNyZWF0ZWQiOiIyMDIxLTA0LTE0VDA5OjIyOjI1LjY1MVoiLCJ0eXBlIjoiRWNkc2FLb2JsaXR6U2lnbmF0dXJlMjAxNiIsIm5vbmNlIjoiZTdlNWU3NWU3ZTkwYjgxOSIsInNpZ25hdHVyZVZhbHVlIjoiNjkzYTU4NTY1M2Q1OWE1Mjk0NGUzOWIyOTg0ZTliZWEyYWE5OTY2M2I1NWNmYWVhMzRkZWY0ODNlMzU4MzE4ZDY3NDdiYmZjYjNmYTMyMmYwYzgzOTg4MDYwYWEyZjM0MDc2YjVhMzhjNDFmNmRjMDZiYmFmM2E1YThhNGJiNjkiLCJjcmVhdG9yIjoiZGlkOmpvbG86NjQxMmVkNjg1MmJjMmNmMGFjZGUzZTUxZGViYjhlM2NjOThjODM4M2E2ZjI5ZDc0NTM1ZTk3MjJkZDI2ZmRiNiNrZXlzLTEifSwiY2xhaW0iOnsiZW1haWwiOiJlbWlsaW9AZXRvbmVjLmNvbSIsImlkIjoiZGlkOmpvbG86NjQxMmVkNjg1MmJjMmNmMGFjZGUzZTUxZGViYjhlM2NjOThjODM4M2E2ZjI5ZDc0NTM1ZTk3MjJkZDI2ZmRiNiJ9LCJuYW1lIjoiRXRvbmVjIEVtYWlsIE9mZmVyIn1dfSwidHlwIjoiY3JlZGVudGlhbHNSZWNlaXZlIiwiaWF0IjoxNjE4MzkyMTQ1NjcyLCJleHAiOjE2MTgzOTU3NDU2NzIsImF1ZCI6ImRpZDpqdW46RW5NU1VQcFpIbm4yUDBZS0FuLWtfZzhJUlJIWU1jVGoxdGExQV9EMFFKX00iLCJqdGkiOiIxZjA0MWFhZDRjZjA0NzkwIiwiaXNzIjoiZGlkOmpvbG86NjQxMmVkNjg1MmJjMmNmMGFjZGUzZTUxZGViYjhlM2NjOThjODM4M2E2ZjI5ZDc0NTM1ZTk3MjJkZDI2ZmRiNiNrZXlzLTEifQ.JMmLn4FK67cEyxGZzsvvwL2Hh5V1_JtoF9HyxSwsbZh7dr5KVg_Rd6OpM_khl22iZiFIyDcPXgbGxRD-hZvlrg
    Sorry for the messed up message...