glass-toolkit issueshttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues2022-12-07T17:22:14+02:00https://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/29Implement a Business Handler2022-12-07T17:22:14+02:00Tiago VenceslauImplement a Business HandlerThese will be different for each service/walletThese will be different for each service/walletDevelop the Glass Wallet System and ecosystem integrationTiago VenceslauTiago Venceslauhttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/28Make it so dapp install handler prompts a confirmation2022-09-02T14:46:42+03:00Vitor NogueiraMake it so dapp install handler prompts a confirmationFollowing issue https://gitlab.ubitech.eu/glass-project/wallet/glass-wallet/-/issues/32 make it so that dapp install handler prompts a confirmation.Following issue https://gitlab.ubitech.eu/glass-project/wallet/glass-wallet/-/issues/32 make it so that dapp install handler prompts a confirmation.Develop the Glass Wallet System and ecosystem integrationVitor NogueiraVitor Nogueirahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/27apihub service with an endless loop on apihub proxy service2022-09-01T03:57:13+03:00Pedro Costaapihub service with an endless loop on apihub proxy serviceapihub service can go into an endless loop when asked to a domain he knows, but not the one he's running onapihub service can go into an endless loop when asked to a domain he knows, but not the one he's running onPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/22Implement the evidence request mechanism2022-08-30T22:47:17+03:00Tiago VenceslauImplement the evidence request mechanismrelates to #19 and #17
set up a test where you install the eGov app (containing the eGovId app) in the wallet.
having that, implement an Evidence request and handler that can, given the path to the evidence, is able to unlock the dapp if necessary, retrieve the requested evidence, and return it (along with either the sRead for the evidence DSU, of the data + signature + signee for that specific bit of info, ex:
- evidence request for `egov.pt.id` -> should return the full EGovID object and the ssi for that evidence;
- evidence request for `egov.pt.id.name` -> should return the name property, the signature for that property and the id of the signer. Topic to discuss: should we wrap this info in a DSU?relates to #19 and #17
set up a test where you install the eGov app (containing the eGovId app) in the wallet.
having that, implement an Evidence request and handler that can, given the path to the evidence, is able to unlock the dapp if necessary, retrieve the requested evidence, and return it (along with either the sRead for the evidence DSU, of the data + signature + signee for that specific bit of info, ex:
- evidence request for `egov.pt.id` -> should return the full EGovID object and the ssi for that evidence;
- evidence request for `egov.pt.id.name` -> should return the name property, the signature for that property and the id of the signer. Topic to discuss: should we wrap this info in a DSU?Develop the Glass Wallet System and ecosystem integrationPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/19Implement the Glass wallet querying mechanism2022-08-18T14:13:00+03:00Tiago VenceslauImplement the Glass wallet querying mechanismA quarta language much be implemented in a way that we are able to map keys to specific evidences.
Eg: to request the name on the id I would expect que request to be something like egov.*.id.name. this should map to the evidence stored in the egov dapp under egov-dapp/id/id/name.
Where the egov-dapp's dsu I'd path contains a EGovIdDapp and the id path of that app contains the egovid dsu (that as a property called name)
The query mechanism should be able to handle the duplication of the id path (it should be easy since we can detect that it is a wallet (has a code folder))
This example assumes the evidences are mounted. This query mechanism should, if no mounts are detected fallback to try and resolve the same via that dapps databaseA quarta language much be implemented in a way that we are able to map keys to specific evidences.
Eg: to request the name on the id I would expect que request to be something like egov.*.id.name. this should map to the evidence stored in the egov dapp under egov-dapp/id/id/name.
Where the egov-dapp's dsu I'd path contains a EGovIdDapp and the id path of that app contains the egovid dsu (that as a property called name)
The query mechanism should be able to handle the duplication of the id path (it should be easy since we can detect that it is a wallet (has a code folder))
This example assumes the evidences are mounted. This query mechanism should, if no mounts are detected fallback to try and resolve the same via that dapps databaseDevelop the Glass Wallet System and ecosystem integrationhttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/18Implement the GlassAuthorizationRequest2022-08-30T17:00:44+03:00Tiago VenceslauImplement the GlassAuthorizationRequestImplement another GlassInputRequest (I would call it Glass authorizationRequest) where the user is prompted to accept/deny the Glass authorized request it received, and it should contain detailed information about what the user is authorizing
This will require an GlassAuthorization data structure to be able to hold all the required paths to the data (if we requesting the id for instance, this path should be something like egov.*.I'd, the the name on the cc it should be egov.*.id.name). The naming is related to the query syntax and will be addresses on a separate issue)
Example:
Evidence request from third party:
- wallet receives Glass authorized request containing the Glass evidence request.
- wallet displays screen containing for each evidence requested:
- the specific documents/data requested (eventually the conditions)
This screen already exists in the UI mocksImplement another GlassInputRequest (I would call it Glass authorizationRequest) where the user is prompted to accept/deny the Glass authorized request it received, and it should contain detailed information about what the user is authorizing
This will require an GlassAuthorization data structure to be able to hold all the required paths to the data (if we requesting the id for instance, this path should be something like egov.*.I'd, the the name on the cc it should be egov.*.id.name). The naming is related to the query syntax and will be addresses on a separate issue)
Example:
Evidence request from third party:
- wallet receives Glass authorized request containing the Glass evidence request.
- wallet displays screen containing for each evidence requested:
- the specific documents/data requested (eventually the conditions)
This screen already exists in the UI mocksPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/17Implement the overall Glass business Authorized request handling mechanism2022-08-17T07:52:05+03:00Tiago VenceslauImplement the overall Glass business Authorized request handling mechanismWhile the generic (programátic) request handling mechanism is already implemented and working, until now only wallet related functionalities (user input requests, dapps install and unlocking, etc are implemented.
These are modeled by the Glass request handlers (object that actually has que logic to resolve the requests. All handlers extend from this), and the GlassRequest object, that represents the request itself (all requests extend this). So far this architecture has proven viable for all 'interior' wallet operários.
We now need to Implement all requests related to glass functionalities.
This starts with the creation of a 'GlassAuthorizedRequest' class.
This class should extend the base class, should have an id so we can reference it in the response, contain the did of the requester, and the Payload should the the GlassRequest itself.
This will also force the creation of another GlassInputRequest (I would call it Glass authorizationRequest) where the user is prompted to accept/deny the Glass authorized request it received, and it should contain detailed information about what the user is authorizing
Example:
Evidence request from third party:
- wallet receives Glass authorized request containing the Glass evidence request.
- wallet displays screen containing for each evidence requested:
- the specific document/data requested (eventually the conditions)
-if the user denies: respond to request with a deny and the request I'd;
-if user accepts: gather the evidences and respond to the message with the requested evidences)
This issue refers specifically to the Glass authorized requestWhile the generic (programátic) request handling mechanism is already implemented and working, until now only wallet related functionalities (user input requests, dapps install and unlocking, etc are implemented.
These are modeled by the Glass request handlers (object that actually has que logic to resolve the requests. All handlers extend from this), and the GlassRequest object, that represents the request itself (all requests extend this). So far this architecture has proven viable for all 'interior' wallet operários.
We now need to Implement all requests related to glass functionalities.
This starts with the creation of a 'GlassAuthorizedRequest' class.
This class should extend the base class, should have an id so we can reference it in the response, contain the did of the requester, and the Payload should the the GlassRequest itself.
This will also force the creation of another GlassInputRequest (I would call it Glass authorizationRequest) where the user is prompted to accept/deny the Glass authorized request it received, and it should contain detailed information about what the user is authorizing
Example:
Evidence request from third party:
- wallet receives Glass authorized request containing the Glass evidence request.
- wallet displays screen containing for each evidence requested:
- the specific document/data requested (eventually the conditions)
-if the user denies: respond to request with a deny and the request I'd;
-if user accepts: gather the evidences and respond to the message with the requested evidences)
This issue refers specifically to the Glass authorized requestDevelop the Glass Wallet System and ecosystem integrationPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/16Correct DApp Ulock requests2022-08-30T18:03:03+03:00Tiago VenceslauCorrect DApp Ulock requestsPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/14Bug in the 'cancel' flows of requests2022-08-18T14:13:00+03:00Tiago VenceslauBug in the 'cancel' flows of requestsWhile the request mechanism is working quite well for most flows (positive installations and errors), the cancel flow (when the user cancels, clicks back, etc) however is not being respected properly
fix thisWhile the request mechanism is working quite well for most flows (positive installations and errors), the cancel flow (when the user cancels, clicks back, etc) however is not being respected properly
fix thisDevelop the Glass Wallet System and ecosystem integrationPedro CostaPedro Costahttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/13Implement Glass DID2022-08-03T21:24:21+03:00Tiago VenceslauImplement Glass DIDTo be able to add custom data to the DIDs, we need to create a new one.
OpenDSU's code accepts registering new DIDs, KeySSIs, etc via a strategy/factory design pattern so adding a new one should not be very dificult.
basically what is needed is to extends the SREAD DID implementation (that creates a DSU, and stores the public key on it) so it accepts a DSU (readSSI) containing data and mounts it. This DSU should be of the type 'evidence' (basically when all the fields are @signed)
Also create a @signedDID decorator to replace the current simple @did. This will allows us to, during the wallet creation process, sign the newly created SignedDID's data (what goes in the 'evidence' DSU) so it can later be verified agains a list of verified issuersTo be able to add custom data to the DIDs, we need to create a new one.
OpenDSU's code accepts registering new DIDs, KeySSIs, etc via a strategy/factory design pattern so adding a new one should not be very dificult.
basically what is needed is to extends the SREAD DID implementation (that creates a DSU, and stores the public key on it) so it accepts a DSU (readSSI) containing data and mounts it. This DSU should be of the type 'evidence' (basically when all the fields are @signed)
Also create a @signedDID decorator to replace the current simple @did. This will allows us to, during the wallet creation process, sign the newly created SignedDID's data (what goes in the 'evidence' DSU) so it can later be verified agains a list of verified issuersDevelop the Glass Wallet System and ecosystem integrationhttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues/7Selects seem not to be querying properly2022-08-30T22:48:40+03:00Tiago VenceslauSelects seem not to be querying properlySet up Glass EnvironmentTiago VenceslauTiago Venceslau