glass-toolkit issueshttps://gitlab.ubitech.eu/glass-project/wallet/glass-toolkit/-/issues2022-08-17T07:52:05+03:00https://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 Costa