Generic security flow - exploration of options

[cliftonc]

• Examples from other B2B scenarios?
• Is it at platform level or at organisation level?
• Can we be clear on defining what is an organization and how security is managed?
• Is there an approach for delegation (e.g. to customer services?)

[cliftonc]

Principles

• School must be in control of data exchanges at all times; they have responsibility from a legal perspective.
• Note: if they aren't able, or want to outsource this they can - to someone who can do it for them.
• Use standard protocols - don't invent our own!
  • Oauth
  • Openid-connect
• An organization is a legal entity.
  • How do we identify them? This needs to be discussed in functional track.
  • How do we do initial verification of administrators?
• IdP is used to identify users and their organizations (tenant), and providing IdP scopes (e.g. to the IdP they are an Administrator)
  • What is the minimum? Administrator / Teacher / Student (not mutually exclusive)
  • All scope names in English
  • Scopes can change, systems should honor them - e.g. don't just cache them from the initial setup.
• Any service is responsible for mapping identities to roles in its own scope (?) Options:
  • The 'first administrator' chicken-egg issue needs to be dealt with ; but this can be done as part of the part of the setup process of the service?
  • Could we use the IdP roles to simplify the initial setup?
  • Should we just not trust the IdP for roles for all services?
  • Roles within a system crucial - we need to be able to control who can approve data exchanges at an organizational level; responsibility sits with each service provider.
    • 'Anonymous' users - all links must contain organization in some way; so that we can lookup the IdP to use for that organization.
• IdP / Organizations need a central service?
• Personal token vs organizational tokens - only an administrator can approve.
• Identifying the administrator of a service is a separate process to actually creating tokens for a specific exchange.
• How long should tokens last?
  • Must be revokable.
• API for requesting access to a service?
  • Revocation - we should notify via webhook / event stream.
• Placeholder organization - this is the legal entity? (confirm with functional track).
• Organizations and legal entities are different things - central discovery service could connect these together.

Prototype

• Lowest level we care about is organization
• API for requesting access to a service
  • Define API - can we find an existing one
  • Use SIS ? Mocked screen to show requesting permissions
• All other API requests use dummy tokens

[cliftonc]

Spoke with @MarcelUntied and @eliashassing154 today re. the other tracks clarifying the conversation above re. Organization definition and a service related to discovery, they will discuss and come back to us.

[eliashassing154]

@stichtingsem/functional-track we'll need to develop a scenario around the "organization" elements above and include in our track