...
- 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 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
- Infrastructure (AWS infra within carrier account)
- 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 stastat reporting
- DH - role for stat agent for stat reporting
- Data Calls
- Application-level
- Regulator
- 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
- Certificate Authority
- Infrastructure Partner
- Developer / Contributor
...