Contributors

Process

The Archiecture Definition Workspace is where we as a community come together to work through the architecture for openIDL going forward.  We take our experiences, combine them with inputs from the community and apply them against the scenarios of usage we have for openIDL.  Below is a table of the phases and the expected outcomes of each.

...

• General
  • an org can authorize members of an org to have a role (role administration)
  • openIDL does not validate identity of each, someone in each org resp for providing/rescinding access
  • Entity resp for nominating person, openIDL can fulfill (Day1)
  • credentials and levels of access, not all need to be credentialed through openIDL, but w/in network (est node w/in network -openIDL, app users w/in carrier node?)
  • access the node and levels above (UIs, etc.), sep from AWS accounts at application level, more study on levels of credentialling needed
  • app standpoint in other things, a service user or app user making connections to db, service-user credentials - app users self service
  • Every carrier has own membership model, CA from openIDL, diff than infrastructure running node, 
  • Fabric perspective, eveyrone who can access node, from pers of deploying chaincode, every user should have Cert from CA (openIDL), PKI, how manage users like logins/etc. diff story, integrate with user management system (email, username, password, 2fa, allow user to login), private keys managed by org, not on device or PC of end user, ususally done when talking about auth end user transaction on network
  • Using UI, to issue request, interacts with chaincode - user who initiates would have to log in, key is managed w/in THEIR org, when user logs in, provides U/P, auth is used internally to check proper priv key, PKI management implmentation, system checks cert, fetches info from cert, level/role, can define what user is capable of, so Fabric can reco user
  • Cert managed by org, in the case of openIDL issuing cert, not each org doing own certs
  • Who manages? openIDL or Ifra Partner can manage on behalf of carrier, could be delegated as a service, manages on behalf of carriers, membership service provider model - any org has to have their own CA and their own internal management of certs
  • Organization: each org that has a node on the network, every node has to have an org and 1:1, one node one org, one org mult nodes
  • openIDL could manage CA, but means all users all nodes, sets of signed certs
  • each person has own Certs, could say "users do transax w/ same cert", every user needs own cert to trace who did what
  • Certs necessary part of infra, how they get issued and managed - topic for discussion, openIDL would have role, theyd have role in membership of priv network, make it easier for members to join
  • Implementation detail rather than biz req
  • Every user needs own cert - every org? each individual interacts should have own cert, not same as how to admin people who access local resources or AWS, diff management of access
  • Not going to have one cert per org and then track w/in cert, need mult certs per org (diff roles and capabilities)
  • which is better in terms of security, each user having own cert is best
  • network management function rather than put it on each org, multi-tenant node (own topic)
• Carrier
  • up to carrier 
  • permission to enter openIDL (not carrier AWS)
  • Roles:
    •  Infrastructure (AWS infra within carrier account)
      • Deploy resources
      • Monitor resources
    •  Application Users (w/in carrier node)
      • Load Data
      • Correct Data
      • LIKE a data call
        • Request makes sense
        • Also potential of multi-level consent
        • Business decision THEN commission EP (not sending EP with request)
      • Messaging 
      • Test Extraction Pattern
    • Administrator
      • central source w/in carrier
      • carriers would say "here is who we want to have certs, roles and authority limits" and openIDL would coordinate for each
• Stat Agent
  • Application-level
    • AAIS (example) attaching extraction pattern (EP) to data call
    • Statistical Reporting
      • Stat agent in charge of the total reports that need to be done
      • stat agent: "If you are doing these lines in these states, these are the reports you are obligated to take part"
      • needs discussion - right now, REG is starting data call, 40 states would have to each create own data call, AAIS attaches EP individually for each line and each state
        • lot of repetition in this process
      • DH: auth of the handbook? "we are doing stat reporting as a stat agent" w/o having to have REG ask for the reports?
      • PA - way things work now, come march all inv in reports, current system REG asks for report, flipped
      • KS - goal of stat agent is resp for managing and completing stat reports, REG  is resp for making data call, stat reporting resp for managing the stat reports, sys needs to work differently than it does now
      • JB - community of carriers reco capability for request of stat reports in future, other parties, done with the consent and agreement of the community of carriers, requests considered legit - stat reports happen, going to occur, not like adhoc data call, stat report provided by orgs that can do so -
      • DH - stat reports are specific and limited to whats in handbook and any other request or REQUESTOR is a data call
      • PA - NAIC Stat Handbook
      • JB - other orgs making data calls on behalf or other types of reporting, network and community recognizes - could have agency that does stat reporting
      • DH - role for stat agent for stat reporting - org that can do stat reports - do we need to recognize Stat Agents  are accredited?
      • JB they are credentialed
• Service Org (analysis firm, infrastructure partner) 
  • Data Calls
    • Role for the stat agent + others
    • DH - EPs would be a role for the stat agent (or Implementation Partner)
    • KS - not comfortable calling data calls a stat-agent-only responsibility
    • KS - regulators could do their own EPs (in house or contracted)
    • REGs not doing execution
    • KS - anyone could do it, inc regulator, if couldn't might have help
  • Extraction Pattern
    • Implementing an EP
    • Responding to feedback on an EP
• Regulator
  
  • Manage Data Calls (CRUD)
  • Collect / Review Reports
  • Messaging
    • DH - similar to a message board, request for data call is out there, when openIDL first discussed, REG asks for "I need info" and message board becomes forum for und intent, can provide feedback on what req is, how easy and readily available info will be, so REG could modify the request (part of the LIKE process)
  • CRUD EPs

...