Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
G glass-toolkit
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 11
    • Issues 11
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • glass-project
  • wallet
  • glass-toolkit
  • Issues
  • #17

Closed
Open
Created Jul 23, 2022 by Tiago Venceslau@tvenceslauReporter

Implement the overall Glass business Authorized request handling mechanism

While 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 request

Assignee
Assign to
Develop the Glass Wallet System and ecosystem integration
Milestone
Develop the Glass Wallet System and ecosystem integration
Assign milestone
Time tracking