DR-003-ARCH-ACL-Concept: Generic Format for Access Control List by christianbe9 · Pull Request #3058 · eclipse-score/score

christianbe9 · 2026-07-01T17:14:52Z

Introducing a common format for an Access Control List (Crypto, SOME/IP,
IPC and further potential usecases), such that it is
only required to use one common parser, one common format for reviews
and also one common "ACL Manager" aka editor for ACLs and also compiler
for the ACL into a binary format.

Introducing a common format for an Access Control List (Crypto, SOME/IP, IPC and further potential usecases), such that it is only required to use one common parser, one common format for reviews and also one common "ACL Manager" aka editor for ACLs and also compiler for the ACL into a binary format. Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>�

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

github-actions · 2026-07-01T17:19:31Z

The created documentation from the pull request is available at: docu-html

GuruprasadBhatL · 2026-07-07T15:51:08Z

A few generic questions :

Is JSON as a config format centrally approved in eclipse/score ?
Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
How is relationship established between ACL config and config of individual features like Crypto/LoLa.

GuruprasadBhatL · 2026-07-07T15:57:00Z

+		  {
+			"uids": 
+			{
+			  "101":{"rights": ["write"],"name": "oem.app.1","version": [],"criticality": "ASIL-B","specifics": {}},


Would like to understand significance of criticality in the current context.

How does it influence ACL configuration.

As we do an ACL my question is: should we include criticality in the config as well to do a cross check/ensure such that there is no mixture "by accident" of criticality due to wrong configuration or something; i.e. can a ASIL application and QM application both interact via one IPC which should not be the case afaik. So this is not a security thing, question is if we also should use this for safety purpose or not.

GuruprasadBhatL · 2026-07-07T19:51:37Z

+		"enum": [
+		  "read",
+		  "write",
+		  "monitor"


what is monitor right ?

Idea behind monitor is (I'm not sure how valid) is only related to IPC, for SOME/IP and crypto its same as read, for IPC the idea is to have only read permission to data and control plane, so that a montoring application cannot interfere with the normal behaviour, however that means you could have partial reads from control plane, therefore control plane might be monitored but not so sure how good of an idea it is. Concrete example was for a Intrusion detection, health monitoring, etc.; e.g. you could check if somebody is blocking in the control pane for too long

I would move that to another schema file which is module specific

christianbe9 · 2026-07-08T14:38:35Z

A few generic questions :

Is JSON as a config format centrally approved in eclipse/score ?
I would say yes, as all other components (e.g. lifecycle) are also using json as config format

Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.

How is relationship established between ACL config and config of individual features like Crypto/LoLa.
ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
Based on the ACL the enforcement is then done in each component

Co-authored-by: Guruprasad Bhat <30743494+GuruprasadBhatL@users.noreply.github.com> Signed-off-by: christianbe9 <christianb_ext@qorix.ai>

ChansAlive · 2026-07-09T15:29:59Z

A few generic questions :

Is JSON as a config format centrally approved in eclipse/score ?
I would say yes, as all other components (e.g. lifecycle) are also using json as config format

Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.

How is relationship established between ACL config and config of individual features like Crypto/LoLa.
ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
Based on the ACL the enforcement is then done in each component

Hi,

ACL config is input to Crypto lib. Considering we have a library daemon architecture for crypto stack, is this still valid? Would this be crypto daemon or still crypto lib?

christianbe9 · 2026-07-10T14:38:23Z

A few generic questions :

Is JSON as a config format centrally approved in eclipse/score ?
I would say yes, as all other components (e.g. lifecycle) are also using json as config format

Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.

How is relationship established between ACL config and config of individual features like Crypto/LoLa.
ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
Based on the ACL the enforcement is then done in each component

Hi,

ACL config is input to Crypto lib. Considering we have a library daemon architecture for crypto stack, is this still valid? Would this be crypto daemon or still crypto lib?

Yes, that was bad wording by me; so ACL would be input to Crypto Daemon (in a setup where you have a mw:crypto for the application which handles the IPC to the Deaemon using LoLa and a Daemon which actually handles the jobs). The crypto lib itself will be part of the application, so it will not include the ACL check (as application would check itself then).

GuruprasadBhatL · 2026-07-13T08:21:49Z

Original Question : How is relationship established between ACL config and config of individual features like Crypto/LoLa.

Response :
ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
Based on the ACL the enforcement is then done in each component

Follow up question :

How is ACL format enforced in config of SomeIP/Crypto ? is is there a way for SOMEIP/Crypto config to inherit (enforce interface schema ) from ACL JSON schema ?

if this is clarified, I have no further questions.

christianbe9 · 2026-07-15T08:00:39Z

Original Question : How is relationship established between ACL config and config of individual features like Crypto/LoLa.

Response : ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component. Based on the ACL the enforcement is then done in each component

Follow up question :

How is ACL format enforced in config of SomeIP/Crypto ? is is there a way for SOMEIP/Crypto config to inherit (enforce interface schema ) from ACL JSON schema ?

if this is clarified, I have no further questions.

From my side fine, makes sense, we can define it such that all ACLs must inerhit this ACL JSON schema included here.

And then if some component needs something in addition we update the main ACL JSON schema such that it always remains central.

FScholPer · 2026-07-16T07:37:38Z

+
+  "services": 
+  {
+	"111":


What is this?

FScholPer · 2026-07-16T07:38:40Z

+		"enum": [
+		  "read",
+		  "write",
+		  "monitor"


I would move that to another schema file which is module specific

FScholPer · 2026-07-16T07:39:15Z

+   Proposed json format & properties (example): 
+
+
+```json


Can we move the example to the bottom and first start with the schema

FScholPer · 2026-07-16T07:39:27Z

+
+   Consequences
+   ------------
+   To prevent each component from implementing compeletley own mechanism for persmission enforcement; the decision should be an alignment on a common ACL format, so that all components can use:


typo permission

FScholPer · 2026-07-16T07:40:07Z

@@ -0,0 +1,553 @@
+# DR-009-ACL-Concept: Common ACL format for all components


I think we also need stakeholder requirements later on

FScholPer · 2026-07-16T07:42:28Z

+		"$ref": "#/$defs/specificValue"
+	  }
+	},
+	"specificValue": {


I think it would make sense to define specific schema and handler of the extension

Christian Becker added 10 commits July 1, 2026 19:09

DR-003-ARCH-ACL-Concept: Added json scheme and reformatted example

ec6e520

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARC-ACL-Concept: Fixxed json formatting

ed0f8ca

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#2 for md formatting

320ff37

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#3 for json formatting

12ac851

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#4 DR Template compliance

fb3ab2c

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#5 DR Template compliance

fbb8660

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#6 DR Template compliance->dr file name

1e64d77

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>�

DR-003-ARCH-ACL-Concept: Fix#7 Raname of DR file 009 --> 003

6c3e23e

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-ARCH-ACL-Concept: Fix#8 Raname of DR file 009 --> 003

6ce5a40

Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

christianbe9 requested review from arsibo and qor-lb as code owners July 1, 2026 17:14

github-project-automation Bot added this to S-CORE Roadmap and TLC - Technical Lead Circle Jul 1, 2026

github-project-automation Bot moved this to Backlog in S-CORE Roadmap Jul 1, 2026

christianbe9 mentioned this pull request Jul 1, 2026

DR-009-ACL-Concept: Generic Format for Access Control List for Crypto #3055

Closed

sunildevda requested review from ChansAlive and GuruprasadBhatL July 1, 2026 17:31

GuruprasadBhatL reviewed Jul 7, 2026

View reviewed changes

Comment thread docs/design_decisions/DR-003-arch-ACL-Concept.md Outdated

GuruprasadBhatL reviewed Jul 7, 2026

View reviewed changes

Comment thread docs/design_decisions/DR-003-arch-ACL-Concept.md Outdated

GuruprasadBhatL reviewed Jul 8, 2026

View reviewed changes

christianbe9 and others added 2 commits July 9, 2026 13:38

PR - suggested changes

0b1e55e

Co-authored-by: Guruprasad Bhat <30743494+GuruprasadBhatL@users.noreply.github.com> Signed-off-by: christianbe9 <christianb_ext@qorix.ai>

PR - suggested changes

258e834

Co-authored-by: Guruprasad Bhat <30743494+GuruprasadBhatL@users.noreply.github.com> Signed-off-by: christianbe9 <christianb_ext@qorix.ai>

qor-lb added the community:architecture label Jul 14, 2026

qor-lb added ft:communication Feature Team Communication ft:security&crypto labels Jul 14, 2026

FScholPer reviewed Jul 16, 2026

View reviewed changes

		@@ -0,0 +1,553 @@
		# DR-009-ACL-Concept: Common ACL format for all components

Uh oh!

Conversation

christianbe9 commented Jul 1, 2026

Uh oh!

github-actions Bot commented Jul 1, 2026

Uh oh!

Uh oh!

Uh oh!

GuruprasadBhatL commented Jul 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christianbe9 commented Jul 8, 2026

Uh oh!

ChansAlive commented Jul 9, 2026

Uh oh!

christianbe9 commented Jul 10, 2026

Uh oh!

GuruprasadBhatL commented Jul 13, 2026

Uh oh!

christianbe9 commented Jul 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants