Participants: Dorn, Pablo, @GOATforMikeD Michael Dechellis, @courtney.king Courtney, @brianwdavis Brian, @Shreya Shreya, @chrowe Chris Rowe, @clevinson Cory, @julietnpn Juliet, @spitla2 Santosh, @nat Nat
Examples of prior work:
OpenTeam Working Group - download of where they’re headed and which group members they partnered with
WRI APIs (ResourceWatch) - uses Okta to ID an individual user, and then each app maintains the user-data relation
Regen Network - Group accounts that allow individual identities to vote on data action
Discussion points:
What are the identity “types” that are needed to be created a priori? What is the core value related to each identity? What are the use cases that are the special sauce to drive adoption?
Real assets: Using software clearinghouses to replicate/supplant the existing paper register of deeds system. We decided that verifying land-user relations was outside the scope of this conversation
Bi-directionality of data actions:
How does a soil test lab send data back? Can that be automated into a data wallet?
What do we do when data sources are not data owners? Often someone enters the data on the farmers’ behalf, due to technical/cultural/other barriers
What about extension/research that doesn’t ingest data from farmers, but trying to push data out to farmers? - Cover crop councils
Open questions:
What’s the superset case that covers as many identities as possible instead of splitting into roles?
What are the differences vs commonality in functionality between user types?
Disclosure/consent - does it live with the data or with the identity service?
Decentralized vs centralized hosting architecture? What’s the schema we need? Can you share identities between federated services?
Where do the fuzzy boundaries exist between Identity, Authentication, and Authorization for these use cases?
What is the right level of abstraction vs domain-specific tools for identity?
Big efforts are in the planning phase, what’s the developer experience anticipated to look like? What’s the timeline?
How do we make identity “invisible”, so that there’s no friction for the end user? Auto-login across tools.
Should this serve all intersections of people and land? Forestry vs commodity ag vs rangeland
How does this identity connect to state identities like SSN?
Use case possible directions:
How can small users group together to share a common identity for purposes like financing? Otherwise there’s no incentive for small users to bother collecting data and ingesting into a wallet.
Start with a single OAuth integration and see what use cases develop organically from user needs
Can a farmer have one login for insurance and conservation tools based on data entered by service providers, extension, researchers?
Upload arbitrary polygons/points and view them on multiple platforms, can there be a unified service that does that?
Can we have a pre-populated polygon population to make selection easier for farmers? User experience is better if you inherit from existing data. Example given was a hunting app that has pulled in non-hunter users.