Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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...
    emixdemix
    @emixdemix
    Did something change in the DB app structure?
    emixdemix
    @emixdemix

    This is the actual error:

    query failed: INSERT INTO "verifiable_credentials"("@context", "id", "type", "name", "issuer", "issued", "expires", "subjectId") VALUES (?, ?, ?, ?, ?, ?, ?, ?) -- PARAMETERS: ["[{\"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\",\"issuer\":{\"@id\":\"cred:issuer\",\"@type\":\"@id\"},\"issued\":{\"@id\":\"cred:issued\",\"@type\":\"xsd:dateTime\"},\"claim\":{\"@id\":\"cred:claim\",\"@type\":\"@id\"},\"credential\":{\"@id\":\"cred:credential\",\"@type\":\"@id\"},\"expires\":{\"@id\":\"sec:expiration\",\"@type\":\"xsd:dateTime\"},\"proof\":{\"@id\":\"sec:proof\",\"@type\":\"@id\"},\"EcdsaKoblitzSignature2016\":\"sec:EcdsaKoblitzSignature2016\",\"created\":{\"@id\":\"dc:created\",\"@type\":\"xsd:dateTime\"},\"creator\":{\"@id\":\"dc:creator\",\"@type\":\"@id\"},\"domain\":\"sec:domain\",\"nonce\":\"sec:nonce\",\"signatureValue\":\"sec:signatureValue\"},{\"schema\":\"https://schema.org/\",\"email\":\"schema:email\"}]","claimId:a92b5d20a3bce1d0","VerifiableCredential,EtonecEmailOffer","Etonec Email Offer","did:jolo:6412ed6852bc2cf0acde3e51debb8e3cc98c8383a6f29d74535e9722dd26fdb6","2021-04-14 09:58:23.607","2022-04-14 09:58:23.607","did:jolo:6412ed6852bc2cf0acde3e51debb8e3cc98c8383a6f29d74535e9722dd26fdb6"]

    2 replies
    emixdemix
    @emixdemix
    @mnzaki looks like the fueling system is down. Is there a way I can refuel it?
    2 replies
    Mina Nagy Zaki
    @mnzaki
    Fueling service has been fixed!
    We also added instructions on how to refuel it yourself next time it's empty, available by just visiting https://faucet.jolocom.io (right now it's not empty, so it just shows the balances)
    emixdemix
    @emixdemix
    @mnzaki I know the SDK already provide the ability to pick and choose which VC to send after a request, however is it also possible to pick a value in a claim with multiple values, rather than the full claim?
    7 replies
    Shekhar-Pathak
    @Shekhar-Pathak
    Hi @mnzaki , all can you please let me know on the supported file formats of self-signed credentials? Especially can we save profile pictures as a self-signed credentials, any other details regarding adding self-signed credentials in the Smart Wallet are most welcome!
    2 replies
    emixdemix
    @emixdemix
    Hi @mnzaki is something changed in the code? interaction.getAttributesByType seems to not work anymore...
    1 reply
    Thomas Tran
    @ichibana:matrix.org
    [m]
    Can anyone share me the document explain how the authentication work? For example, if need to login to the website using the jolocom wallet to scan the QR code?
    7 replies
    Denver
    @dnaicker
    image.png
    Hi everyone, I started using Jolocom and when combining with React-Native and using the metro file suggested, I get a buffer error when creating a buffer error
    image.png
    I will try to log an issue on github
    Denver
    @dnaicker
    I added it to : jolocom/jolocom-lib#461
    emixdemix
    @emixdemix
    hello is "SyntaxError: JSON Parse error: Unexpected identifier "EntityMetadataNotFound"" on createAgent an issue you know about? Just started popping up...
    emixdemix
    @emixdemix
    @mnzaki yes, that error occurs now and cannot create agents on the mobile device. ProcessJWT function keeps failing. Did anything change? Thanks!
    Shekhar Pathak
    @shekhar.bits_gitlab
    Hello, @mnzaki, all. We are facing issues in executing demos from https://interxns.jolocom.io/, any information regarding this is appreciated.
    Lungu Cristian
    @clauxx
    Hello @shekhar.bits_gitlab, can you please provide more details about the issues you are facing? Also, please check out the https://github.com/jolocom/smartwallet-app repo, which was recently updated with a new version of the SmartWallet.
    Shekhar Pathak
    @shekhar.bits_gitlab
    Hello @clauxx, actually we are still on SW1.x and have not moved to SW2.x released yesterday. We have planned releases and our usecases similar to present under https://interxns.jolocom.io/, were working fine. But for recent release, we see that, demos using SW1.x code are failing, I can share error messages with screenshots later. Issue has also been raised at jolocom/smartwallet-app#1698
    Any help to get fix demos https://interxns.jolocom.io/ execution with SW1.x would be really helpful. We see that similar issues are also raised here already even with SW2.x playstore app which has been made available sometime in the past.
    Lungu Cristian
    @clauxx
    @shekhar.bits_gitlab It doesn't seem like we can reproduce the issue you mentioned. We tried both the 1.11.0 and 1.11.1 versions of the SmartWallet against the Avalon and the Interactions Demo without any issue. Can you try to either update to 1.11.1 or try to install a clean version of the application (you may have some issues with building due to the NetInfo package, which you can fix by updating it to 6.0.2).
    Lungu Cristian
    @clauxx
    @shekhar.bits_gitlab alternatively, what could be happening is that the react-native-jolocom package updated the sdk to a version that is incompatible with the older versions of the SmartWallet. Try to lock the version of the react-native-jolocom package to 2.1.0 by removing the caret from package.json.
    Shekhar Pathak
    @shekhar.bits_gitlab
    @clauxx Thank you so much for the suggestions, 'll check and update here.
    Dennis von der Bey
    @DennisVonDerBey
    Hey! One quick question - what's is the intent of using IPFS to store the did document instead of having it as part of the ethr chain? :) Your iOS app looks beautiful btw!
    Shekhar Pathak
    @shekhar.bits_gitlab
    @clauxx we could resolve the issue by locking react-native-jolocom@^2.1.0:
    to version "2.2.0". Please check jolocom/smartwallet-app#1698
    Lungu Cristian
    @clauxx
    Hey @DennisVonDerBey, since storing data on the ETH chain is expensive, our did:jolo method stores only the DID and the IPFS hash of the DID Document on-chain. This allows to maintain the integrity and the bond between the DID and the DID Document, while not overloading our ETH contract with unnecessary data. P.S. Thank you! :)
    @shekhar.bits_gitlab Glad it solved your issue! Please consider upgrading to the latest version of the SmartWallet though :)
    Shekhar Pathak
    @shekhar.bits_gitlab
    @clauxx quick question, does the backup and recovery of smartwallet data associated with user's DiD (basically IPFS documents related to user's DiD) work with SW2 now?
    And thanks, we do plan to upgrade to SW2.x
    Lungu Cristian
    @clauxx
    @shekhar.bits_gitlab Currently there is no functionality for recovering the SW data (i.e. Verifiable Credentials, JWTs). The recovery during the on-boarding process will only recover the user's identity (private keys) from a BIP39 mnemonic, without the data associated with it since it is stored locally. Nevertheless, the functionality of backing up the user data is highly prioritized on our roadmap.
    Shekhar Pathak
    @shekhar.bits_gitlab
    Thanks @clauxx for these details and information.
    timjanssen.crypto
    @thwjanssen89_twitter
    Where can I find jolocom API documentation? On google I can only find this: https://jolocom.github.io/jolocom-sdk/1.0.0/api/ but that doesn't seem up to date
    1 reply
    min ju
    @ilovelili
    Hi @mnzaki I want to check the status of Jolocom-cli (https://github.com/jolocom/jolocom-cli) is this repo deprecated?
    2 replies
    min ju
    @ilovelili
    since I found quite a lot of gyp errors when building