# Authorization Agent UI/UX ## Initial state ### Connecting We should use something simple to avoid flashing different app states while authentications are still being determined. * Simple indicator that app is bootstrapping / loading ### Frontend needs authentication We should be able to determine it relatively fast * *Login* view with short explaination of Solid Login * Clarify that the input is the idp, not the webid * Validation for the input * (Low prio) Handle rejections from @inrupt/solid-client-authn-browser ### Backend needs authentication This one can take a little longer to determine since we need to request session state from the service * Create "connect to server" screen with explanatory text of why the a second login is needed ### Both ends authenticated * Conecting view while determining * Dashboard view when ready * List of application registrations * List of social agent registrations ## Authorizing Applications * Initial implementation of authorization screen to be based on (https://solid.github.io/data-interoperability-panel/primer/authorization-agent.html#gathering-authorizations). * Authorizing new application (will create new registration) * needs to make it clear that application is new * Re-Authorizing existing application * will show to the user details of current authorization (incl revoked access) and the diff (diff - low prio) * same as "Change authorization for selected Application" (below) ### Notes * Both flows need to handle case where new data registration has to be created * (low prio) user should be able to review source of the shapetree for that registration. Use the domain as the verifying point. Have a static list of trusted sources (shapetrees.pub, etc). * possiby get information if that's first from that source or other data registrations for different shapetrees from that source exist * (low prio) if user has more than one Data Registry they should be able to select which one. For now we could just show URL of the Data Registry to label them. ## Managing registered Agents ### Applications * List registered Applications * Change authorization for selected Application (incl. revocation) * start with only revokation * Add modification later (low prio) ### Social Agents * List registered Social Agents * Change authorization for selected Social Agent (incl. revocation) * start with only revokation * Add modification later (low prio) * Add social agent based on [Access Receipt](https://solid.github.io/data-interoperability-panel/specification/#access-receipt) * This has to be done very carefuly to avoid [impostors](https://github.com/solid/authentication-panel/issues/161) * Use case: social agent A shares data with social agent B. B does not have a registration for A. ### Notes * Both cases should provide distinct list of agents with active authorizations and agents with revoked authorizations. ## Managing Data Registrations Currently we might only expose adding new registrations by authorizing applications. Most users will very unlikely paste shapetree IRI manually to create new one. ## Push Notifications * (low prio)Service requires re-authentication (eg. refresh token revoked etc.) * Needs changes on the BE and FE * Create designs for the FE * Access Receipt received (also Access Request) * Inbox design ## Analytics (low prio) eg. https://sentry.io/welcome/ * Add config (through components.js)that allow to use analytics services like sentry.io.