...

Subscribe to Report (automate initiation & consent)

Identify Report

• Who?
  • originally everyone participating in call from Regulators to Carriers to Intermediary (Participants)
• What is it (metadata)
  • Naming it 
  • identifier
  • Requestor
  • type of input
  • generation source
  • line of business
  • what output should look like
  • explicit math for aggregation
  • Purpose of data (what being used for)
  • similar to what is captured on a data call
  • DR - stab at making a vers of this, idea of what it should be (ref reqs), see how it looks, whats missing, etc. - find gaps as opposed to trying to be complete here  - for todays putpose some metadata along lines of reqs, would we do first req/draft of what it would look like, anything missing? (feels like reqs lite)
  • KS - info req section in reqs table, first iteration/sol will highlight gaps
  • SK - any existing samples of data calls/reqs? metadata assoc w/ request, match up, covered in the list?
  • PA and KS to discuss what will be shared, integrating w/ other depts, large list of data calls from other systems, working with ops teams to bring it together, high level looking to make big improveements on metadata and reqs
  • SK - date thinking couple (date of req, deadline data, expiration date)
  • KS - for a report these are the fields we fill in: (a la data dictionary definitions), what data call was intended to capture but inc all of details Dale pointed out, there is bridging vs pointing back to reqs, layout for report - THIS IS WHAT WE ARE TRYING TO DO/WHAT THIS REPORT IS
• Identify Stat Reporter

...

• PA - submitting report, gen report and put into S3 bucket, downloadable link, part of the data call will have URL of report, carrier goes to URL and downloads document - security is on the S3? anyone download from link? Password, Cognito?
• AC - no security, public link, right now avail indefinitely
• PA - EP and URL is good, email / messaging to let Carrier & Reg know report was avail, with message can tie in password, report public is a security hole

Permissioned Access

• GAP - final reports are currently public (possibly indefinitely)
• no report data accessible to the public
• All entities on the network are known and have credentials (Carriers, Regulators, Stat Agents, openIDL)
• MFA required
• Credentials should be recoverable
• Credentials need to be renewed every 12 months from issuance
• Identity + Authentication schema tbd
• SOC2 compliance (Sean W. Bohan to do some digging)
• w/in carriers - finite set of people with access to reports, credentialed w/in carrier (NEED SESSION ON ROLES)

Roles

Deliver to participants (carriers)

• KS - anyone participating in a data call should be able to see report associated w/ that data call? Only participants?
• DH - didn't pay, can't play (carriers that do not participate do not get to see end result, carriers that participate DO get to see result)
• BH - market share perspective (in reqs already)
• KS - can't see things/ details before cleared % requirement - should be able to see what YOU (as a carrier) would contribute, but now whole (or other carriers) until the report is complete

Deliver to Regulators (requestors)

• KS - requestor needs to be able to see if they have access to data call, and see one or more reports related to that data call - if you can get to data call you can get to the report
• DH - participants and REGs, credential who can see it?
• KS - can't get into UI w/o credentials, report viewer? 
• DH - for carrier and requestor, dont want low level analyst sending report to newspaper
• KS - levels of access to access a report, true of creating and a lot of functions (regulator has login and can see but not create data calls) - finer-grained permissions
• DH - once submit a data call to a state, no control over it
• KS - requirement not to be able to download it, method to keep them from abusing, sharing file
• DH - NOT editable 
• Watermarking reports? maybe not a requirement
• DH - only the requesting body can get the report
• KS - how does it relate to carriers being able to get report?
• DH - if EL does a data request and gets results doesn't mean GeorgeB can get results - needs to do his own data call
• KS - scope of the data call 
• DH - recipients limited to state requesting data without further approval - dealoing with data calls too - it would be nice if REG as making request would identify if the request is adhoc or recurring?

Receipt/Notifications

Auditability/Traceability

Exception handling

Data Call

Communications for resolving conflicts, etc.

Load Data

Create Data Call

Like Data Call

Issue Data Call

Subscription to Data Call

Consent to Data Call

Mature Data Call

Abandon Data Call

Clone Data Call

Deliver Report

Access and Roles

Permissioned Access

• GAP - final reports are currently public (possibly indefinitely)
• no report data accessible to the public
• All entities on the network are known and have credentials (Carriers, Regulators, Stat Agents, openIDL)
• MFA required
• Credentials should be recoverable
• Credentials need to be renewed every 12 months from issuance
• Identity + Authentication schema tbd
• SOC2 compliance (Sean W. Bohan to do some digging)
• w/in carriers - finite set of people with access to reports, credentialed w/in carrier (NEED SESSION ON ROLES)

Roles

• 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
  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
      node)
      • Load Data
      • Correct Data
      • Like data call
      • Sending Messages
    • 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
    • Data Calls
• Regulator
• • • • 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

•  openIDL
  • Certificate Authority
    • Possible for each org to have their own CA but felt it would be simpler at beginning for openIDL to deliver certs 
    • not require carriers to use existing CA 
    • Coordinating services of CA, some degree of review of who applicants are, governance angle, some notion of membership and who is joining/on network
  • Network Monitoring 
  • Network Administration
• Infrastructure Partner
• Developer / Contributor

Deliver to participants (carriers)

Deliver to subscribers (requestors)

Receipt/Notifications

Auditability/Traceability

Exception handling

Data Call

Communications for resolving conflicts, etc.

Load Data

Create Data Call

Like Data Call

Issue Data Call

Subscription to Data Call

Consent to Data Call

Mature Data Call

Abandon Data Call

Clone Data Call

...

• • Implementation Support
• Infrastructure Partner
  • Set up nodes
  • Maintain Nodes
  • Report on Network Health
  • KS - role at the top level, can provide support for carriers that want to participate and necessary level (onboarding, training, etc.) - they are knowledgeable and expert w/ tech stack and apps w/in openIDL, provide support where necessary - Use experience to recommend improvements to system overall, provide support
  • Participate in governance
• Developer / Contributor
  • Some reports require implementation beyond EP
  • Application development running on openIDL
  • Participate in governance

Application Components

Data Sources, Sinks and Flows

...