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

We can define it in a seperate schema for sure, but I would like to keep it as generic as possible, as more abstractions often are confusing; is there anything else except read and write which is related to communication?
read -> subscribe/1:1/consume/request aka receive response
write -> publish/1:1/produce/send response
monitor -> observe, without ability to lock while reading

Then we could define this in a seperate scheme with those 3 base rights, and projects could, if they want refine it.

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

anmittag · 2026-07-24T08:18:37Z

@arsibo please review

Changes applied: - example moved to bottom - rights enum in seperate schema - access control rate limiting for jobs and memory - updated read, use and write right structure - renamed tlsenable, ipsecenable, macsecenable for better understanding to precondition_*enabled Singed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

anmittag · 2026-07-31T06:41:35Z

@christianbe9 any update on the PR?

christianbe9 · 2026-07-31T06:49:58Z

Hi, yes we had a breakout session yesterday with crypto specifics, so there will be new updates coming today; after this we will also start the discussion within the architecture group, i.e. com (lola/someip). When this is finished as well the PR is ready to go.

Changes applied: - added support for profiles (optional) - added support for limiting (rate and memory limits) - added support for functional access rights Singed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

ChansAlive

Initial review

Added the certspace as rights slightly differ (especially the standard read/use rights). Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

anmittag · 2026-08-20T12:14:30Z

@christianbe9 please update your PR according to the discussions. set it to draft if not finalized

Changes: - removed keyspaces - rename of certspaces to truststore, write to modify - added "default" to operationalRights - added descriptions - add providespecific Signed-off-by: Christian Becker <chrsitian.becker.ext@qorix.ai>

- Added property to the crypto->truststore Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

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

github-actions · 2026-08-26T08:32:01Z

Documentation preview for this pull request is available at:
pr-3058: https://eclipse-score.github.io/score/pr-3058/

ChansAlive · 2026-08-26T19:44:17Z

+		"confirmTrusted": {
+			"description": "If put to True, then even though an application A might have rights to modify/update a certificate in a certificate slot, the owner of the truststore must accept it, otherwhise it will be marked invalid for the truststore. If put to False, if application A has rights to modify/uipdate a certificate, then its by default trusted by the other parties as well.",
+			"type": "boolean"


I would say this shall be the property of the membership for a certslot in a truststore.

ACL shall define who is able to modify the truststore. Whether a certificate is conditionally accepted or not shall be the property of the truststore, which can then be influenced by the user having the modify rights.

PS: This is planned to be a config of the crypto configuration for the trust store members rather than in ACL.

christianbe9 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

anmittag assigned christianbe9 Jul 24, 2026

christianbe9 force-pushed the dr_003_arch_acl_concept branch from 09c8935 to cd6c8bc Compare July 24, 2026 22:32

DR-003-ARCH-ACL-Concept: Added limiting and permission for crypto

2fb14af

Changes applied: - added support for profiles (optional) - added support for limiting (rate and memory limits) - added support for functional access rights Singed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

ChansAlive reviewed Aug 5, 2026

View reviewed changes

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

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

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

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

DR-003-ARCH-ACL-Concept: Added Certspace

574c1dc

Added the certspace as rights slightly differ (especially the standard read/use rights). Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

christianbe9 added 4 commits August 22, 2026 22:07

DR-003-arch-ACL-Concept: Updated the schema for crypto

ff82d68

Changes: - removed keyspaces - rename of certspaces to truststore, write to modify - added "default" to operationalRights - added descriptions - add providespecific Signed-off-by: Christian Becker <chrsitian.becker.ext@qorix.ai>

DR-003-arch-ACL-Concept: Addding "confirmTrusted" property

fcf0843

- Added property to the crypto->truststore Signed-off-by: Christian Becker <christian.becker.ext@qorix.ai>

DR-003-arch-ACL-Concept: Fixxed typos

265a63c

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

DR-003-arch-ACL-Concept: Added version

e0f1e94

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

ChansAlive reviewed Aug 26, 2026

View reviewed changes

sunildevda mentioned this pull request Sep 9, 2026

Configuration of Crypto eclipse-score/inc_security_crypto#219

Open

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

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!

Choose a reason for hiding this comment

Uh oh!

anmittag commented Jul 24, 2026

Uh oh!

anmittag commented Jul 31, 2026

Uh oh!

christianbe9 commented Jul 31, 2026

Uh oh!

ChansAlive left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

anmittag commented Aug 20, 2026

Uh oh!

github-actions Bot commented Aug 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants