Workspace concept (and OIDC keycloak implementation)

Hello :slightly_smiling_face:,

I started implementing OIDC for Digicirco ( [belgian] cross platform ERP for local food systems where OFN is the sales platform) and it made me think about API and architecture :smile:, OIDC is a very standardized API (and that’s good !!). I’m also interacting with Farm Connect (France, Théo-Paul).

Let’s think high level. If you look at ebay, airbnb, amazon, everybody can buy and sell. It’s not specific for an enterprise. So the main concept here for me would be an account. So an account can buy and sell (spoiler alert, account will be replaced by workspace later on, account concept is too much linked with a single member).

Now imagine, I, as a person, am buying local food for my family. But now I want to start a garden and sell some of my produce to my neighbour. How do I do not to mix orders for seeds from a local seed grower and my family orders ? Should I create a new account or introduce a new concept : workspace. Workspaces are cool : look at slack workspace, notions workspace. You can create as many as you want and invite people to it. But how do you make sure people are who they claim they are (important for trust especially when money gets involved) … you can’t in google and slack, I can be Olivier in the first workspace and Ned in the other. For instance, airbnb wants a single workspace/account per person, so they want to enforce identity. Enforcing identity is often taken at an administrative zone level (national, …) : registering a person at birth, registering a business (an enterprise). So there are ways to make sure a person is a real person and a business is a real business. Since OFN uses the concept enterprise so I take it and I add the concept of person (very much the same as a user but an identified one and making sure there are no duplicates). I keep in mind that my garden project can very well become an enterprise later on (it’s a bit like turning a workspace into an enterprise workspace).

So we have workspaces, persons and enterprises. Persons are linked to enterprises (legally : employee, member, …) and enterprises are linked to enterprises (legally as well : consortium, cooperative, …). Let’s say a workspace can have multiple members. Since more and more horizontal hierarchy is the way to go (you don’t have a boss, you have a coordinator). Let’s put all enterprises at same level and put their members at the same level too. Members have roles inside an enterprise and an enterprise can ask to play a role for another enterprise.

( uses to concept of organization, same as enterprise)
(workspace concept is also pretty good to create test workspaces)


How to use all this with oauth / OIDC :smiley: ?? And practically implement it in keycloak ( seems very promising !!) ?

The way I did it in keycloak (single realm) :

An workspace is a keycloak group (small generated id as group name) and a person is a user. So I can say this person belongs to this workspace by adding his user to the group related to the workspace.

(A pity you can’t add a role to the membership in keycloak …) Each platform/domain is represented by a client in keycloack. I created the resource type “workspace” so I can add a specific workspace resource to a client and give it some scopes such as shipment:handle meaning I give the shipping platform the rights to handle the shipping of my small garden workspace. Based on the role of the user (realm role or client role), I can decide which scopes he gets.

The user OIDC token has a groups attribute (part of OIDC standards), array of workspace urls (example:

Hello @olivier5741

If I have understood correctly, there are several aspect here:

  • the ability to more smoothly sell in various form and context. For that, I think you might be interested by something we call the “network feature” : Network - phase 1

  • verifying user credentials. On this topic you might be interested by this standardization work:

Just FYI I’m not sure there are OFN instances that do allow physical persons to sell on the OFN. As far as I know all instance operate with charging enterprises and organizations.

1 Like

I am missing the technical element - but want to agree with what Rachel notes above. One of the big strengths of OFN (I believe) is that it encourages the development of distributed food networks (and networks link together into food systems) We are improving this with the network features Rachel notes. In many platforms, in order to be a ‘seller’ some aspect of my business needs to be verified and approved. Often, e-commerce platforms require some kind of business proof for example. But in OFN - we see that strong food systems need to embody both ‘formal’ (businesses) and ‘informal’ (non businesses) enterprises. An example - we have an OFN hub in my city (Bailey’s Local Foods). ONe supplier to this hub is Canada’s largest organic produce distributor. This supplier enterprise enters is business number (credentials) … Another suppleir to this same hub is a community garden. These enterprises sell ‘side by side’ with equal ‘power’. This does not happen in most e-commerce - where big fish get tools to help them get bigger… This diversity of ‘enterprises’ and equity across enteprises and openness to become an enterprise - is the strength of reslient food systems, and I think OFN is designed to build on this strength. (Sorry if this isn’t relevant, its just the post made me think of it.)

I should have a added a real world example :D. We’ve a real world (family) farm : Valère is the farmer, everything is in his name. He is raising beef and milk cows and sells meat packs. Marie is the cheese maker, uses the milk produced on the farm and sells/transports cheese to restaurants and supermarkets. Anaïs is in charge of the farm market held on the farm every saturday, gets goods from other local producers + some farm goods. Everything is invoiced under Valère’s name, Marie doesn’t live at the farm and they all handle their business with their phone (except invoicing) . Valère is in charge of the farm, Marie of the cheese and Anaïs of the market. How do you implement this on OFN → 3 enterprises but you can’t transfer orders from one to the other, 1 enterprise but everything is mixed up. There comes WORKPLACE :smiley: → 3 workspaces : farm, cheese room and market.

If everything was on paper, it would make a lot of sense, that’s where a document (order, delivery notice, invoice) would be !! It’s been a winning concept for many tools : Google … workspace, Slack … workspace, Notion … workspace :smiley: .

A workspace can be linked to a customer, an organisation (so far OFN enterprise encloses the concept of workspace and organisation together), a team !! Super powerful …

@olivier5741 why do you need to transfer orders? you can create several shops on the OFN. In the business details of the enterprises running these shops you can put the HQ address of Valère in order to have his name on all the invoices. Valère can have permissions on all shops.

For complex cases of building up products from different producers and being transparent about it ot customers // easing the chain of sale possibilities, network is really where we put most of our resources in so far and collected the most feedback from our users. I’m not saying that workspaces are not interesting, I’m just unsure of what problem they are solving. Maybe they could be interesting addition to network in some cases, but the two would need to work together as network is really on it’s way to be worked on.

Further to above: putting the HQ address in business details of all shops will get that name on invoices. But in addition - you need to think about where and how your ‘system’ wants payments directed and how orders are shipped or picked up. The OFN app gives 3 ways (that I see) for pickup and payment: 1. products are physically aggregated and/or paid for in one place before distribution (hub model), 2. multiple pre-set locations for pickup/delivery or payment (distributors in outgoing of an OC) 3. each individual producer hosts a pickup/delivery and takes payment (the OFN ‘groups’ model). What we do NOT have is ‘split payments’ or ‘drop shipping’ - where there is one marketplace receiving customer orders, and the app sends payment to each supplier’s wallet directly, and/or conveys separate shipping/pickup details for each product to the buyer & supplier (Amazon, Etsy…). I"ve long dreamed of being able to split payments and offer drop shipping.

There is another hack on this that might work - if we had the capacity to have multiple carts open simultaneously would help with the need for splitting payments/drop shipping. You could set up a ‘group’ with all your suppliers (who have setup whatever payment and shipping/pickup they need) and with the invoicing address as you want…, Then set up a ‘display only’ store where customers peruse products. When a customer sees a product they want they go to that supplier/producer store and buy. Then they see another product they want and they go to a second producer store to buy…