Providers, Services, Identity Use

Created by

Remus Golgot

Last updated Jan 17, 2019

Actors :

  • PROVIDER

  • USER

Service states:

  • ACTIVE ( default after creation )

  • INACTIVE ( result of an "Inactivate Service" action performed by the PROVIDER )

Actions :

  • Provider Search ( made by USER )

    • Q : How do we authorize/certify/verify providers/services ?

    • A : In order to have a provider available on our "marketplace" we should have a partnership signed, so it will be easy for us to identify which Persona is whom.

  • Service creation ( made by PROVIDER )

    • Service Name, Description, Attributes Needed ( list of attribute types ), Number of validations required per attribute

    • Service will be active and public by default

      • Any user can immediately send identity use requests to this provider's service

State transitions:

  • Create a new Use Request ( made by USER )

    • Next Request State : PENDING_APPROVAL

    • Requests cannot be created for disabled (inactive) services

Status\Action APPROVE DECLINE END CANCEL
PENDING APPROVAL ACTIVE DECLINED CANCELED
DECLINED
ACTIVE ENDED
ENDED
CANCELED
  • End Identity Use ( made by USER )

    • Stops the share of an attribute with a provider for which an Active Identity Use request exists

      • Interrupts any future updates on the impacted attribute(s) be visible to the provider

      • Ultimately, the provider already has the "old" attribute(s) value(s)

        • There is no way to delete information on the blockchain

Notes:

  1. Even though the USER selects a provider's "SERVICE" as target of an identity use request, the request itself will ultimately be made towards a PRSN address ( at blockchain level ), controlled by the said provider

  2. For transparency purposes, we will enforce a rule that prohibits a provider to use multiple PRSN address for multiple services under his control. Instead, he should have exactly 1 address for all interactions made through his services.