- From: <carsten.stoecker@spherity.com>
- Date: Sat, 23 Aug 2025 15:29:43 +0200
- To: "'Alan Karp'" <alanhkarp@gmail.com>, "'Bob Wyman'" <bob@wyman.us>
- Cc: "'W3C Credentials CG \(Public List\)'" <public-credentials@w3.org>
- Message-ID: <044501dc1431$fca66ab0$f5f34010$@spherity.com>
Hi all, Access control, policy engines, user‑managed access, and Zero Trust Architecture (ZTA) are underexplored in our decentralized identity work. Most of us focus on human identity. The recent “Access Control” thread shows there is energy to go deeper. Alan Karp’s hazard‑driven approach, Bob Wyman’s questions on composition and DRM/ODRL, and Daniel Hardman’s notes on overlapping delegations are all very relevant. I want to share what is happening in the industrial space in Europe. In short: there is a running, operational stack that applies ZTA ideas, uses policy engines, and enforces access rules at even (!) the data asset level. WHAT IS CATENA X AND ITS LINK TO MANUFACTURING X Catena‑X is an automotive data ecosystem. https://catena-x.net/ It standardizes sovereign data exchange across the supply chain. It is a lighthouse under the Manufacturing‑X program. https://www.bundeswirtschaftsministerium.de/Redaktion/EN/Dossier/manufacturing-x.html Catena‑X is in operation in Germany and the EU. It is expanding abroad. There is a North America hub at US-based Automotive Industry Action Group (AIAG). Japan is active (first Onboarding Service Provider certified; PoCs). China has a multi‑company pilot. I have not seen a formal South Korea “hub” announcement yet, but KR is on the Catena‑X country clearance list. There are discussions to connect Chinese and EU automotive supply chains at a larger scale. The Catena‑X “List of Members” (dated July 1, 2025) includes global organizations such as Accenture, Amazon Web Services, Flex Ltd., Microsoft, and Ford Werke GmbH Manufacturing-X is a German and European initiative to build a sovereign data space for industry that connects energy, manufacturing, automotive, machinery, aerospace, chemical industry, process industries, and related supply chains. HOW ACCESS CONTROL IS DONE (SHORT VERSION) 1) Connectors are the enforcement points. Participants deploy an Eclipse Dataspace Components (EDC)–based connector. Connectors publish data offers, negotiate contracts, and gate access. Usage control is part of the protocol. 2) Policies travel with the data offer and the contract The Dataspace Protocol (DSP) expresses usage rules as Policies and reuses ODRL terminology (permissions, prohibitions, duties). Catena‑X profiles ODRL and requires a Catena‑X ODRL profile on policies. 3) Wallet‑to‑wallet trust via DCP Catena‑X defined the Decentralized Claims Protocol (DCP). It adds an identity/claims overlay (VPP/CIP/IATP) to DSP. Open docs show DCP integrated with existing IAM (e.g., Keycloak as token issuer). The Catena‑X connectivity spec binds this to access tokens, refresh endpoints, and TTLs. That refresh flow points to RFC 6749 §6. So, DCP aligns with OAuth2* token mechanics even as it moves claims in wallets. At Spherity we have added an EDC/DCP integration module to our European Business Wallet (EUBW-ready) solution. This anchors the legal person’s identity in the business registry, which provides the legal proof of existence of a company. Based on this we can establish a full end-to-end trust chain: Business Register => EUBW (LPID) / verifiable enterprise KYC => compliance assertions, licenses, roles => powers of attorney and other delegations => EDC-to-EDC (or agent-to-agent (A2A)).** Verification takes place at the policy engine level. We are implementing this architecture in the WE BUILD Large Scale Pilot of the European Commission together with EU business registries to establish such a trust chain for authorization and delegation. * NOTE: At Spherity we recommend the shift away from OAuth2-based protocols. These protocols are now embedded in an operational system, which makes advocating for a transition more difficult. ** NOTE: The same trust and policy mechanisms apply to Trusted AI as well as to the integration of wallets in A2A protocols. Designers of A2A protocols can at least draw useful lessons from Catena-X. 4) Verifier/ Policy Decision Point(PDP) pattern is explicit Access decisions happen at the provider side (connector/PDP). That matches the list discussion where “the verifier (PDP)” evaluates grant + context, and where “Chinese Wall”‑style constraints can be policies. 5) ZTA alignment Short‑lived tokens, continuous verification, least privilege on each transfer, and no implicit trust of the network. This lines up with NIST SP 800‑207 ZTA guidance. Catena‑X specs include explicit token expiry and refresh guidance to force re‑auth. 6) Asset‑level enforcement exists The Tractus‑X change log shows an EDC data‑plane access‑control extension for submodels (AAS contexts). This is enforcement at the data asset boundary, not only at login/session. NOTES FOR THE CCG BASED ON THE THREAD (BRIDGING TO INDUSTRY PRACTICE) * Composed delegations are a real hazard. Industrial policy engines must prevent harmful composition unless explicitly allowed. Bob’s example (combining U and D from different delegators) shows the risk. In Catena‑X/DSP, you can express “no composition” or “mutual exclusion” via policy and enforce it at the verifier. * Policy != mechanism. Alan’s point to focus on hazards, not only mechanisms, maps well to industry deployments: the verifier enforces machine‑detectable constraints; humans handle the rest. * ODRL as common language. The thread asked whether we can borrow from ODRL for capabilities/DRM. In EU dataspaces that is happening today: DSP uses ODRL terms; Catena‑X mandates an ODRL profile. * User‑/policy-managed access remains underused in DID. In industry, the “user” is often an organization or a system owner delegating to agents and services. The control point sits at connectors and wallets, not browsers. The CCG mailing list’s OAuth/OID4VC concerns reflect this shift. https://lists.w3.org/Archives/Public/public-credentials/2025Aug/0094.html . WHAT CATENA X / MANUFACTURING X CAN TEACH US * Treat org‑to‑org as first‑class. Keep a persistent, authenticated channel between wallets/agents. Event‑driven updates, revocations, and re‑keying must not depend on a human redirect. * Make policy objects explicit and portable (ODRL profile). Attach them to offers and proofs. Evaluate locally at the verifier (connector) on every request. * Support composed delegation and cross‑issuer checks as policy (anti‑combination rules, Chinese Wall, k‑of‑n). Keep the PDP authoritative at each boundary. * Keep data‑asset‑level enforcement. Do not stop at identity. Enforce at the dataset/submodel. Log, audit, and prove obligations were met. POINTERS (SPECS, CODE, AND PROFILES) Catena‑X standards overview (incl. DCP/VPP/IATP, ODRL profile): CX‑0018 Dataspace Connectivity; CX‑0149 Verified Company Identity. https://catenax-ev.github.io/docs/next/standards/CX-0018-DataspaceConnectivity DCP spec (wallet‑to‑wallet identity and claims overlay): Eclipse DCP (site + proposal notes on Keycloak integration). https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0-RC4 DSP (protocol uses ODRL policy terms): Dataspace Protocol 2025‑1 RC. https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol Eclipse Dataspace Components (EDC): project overview; publications (DIDs); “MinimumViableDataspace” demo. https://projects.eclipse.org/projects/technology.edc https://github.com/eclipse-edc/Publications/blob/main/Identity Management/DID_EDC.md <https://github.com/eclipse-edc/Publications/blob/main/Identity%20Management/DID_EDC.md> Tractus‑X EDC & Identity: Tractus‑X EDC repo; IdentityHub with DCP CredentialService and STS. https://github.com/eclipse-tractusx/tractusx-edc/blob/main/docs/development/dataplane-signaling/tx-signaling.extensions.md WHERE THIS LEAVES US (FOR BUSINESS/INDUSTRIAL WALLETS) Build strong business wallet capabilities using these mechanisms. Focus on org‑to‑org channels, portable policy, verifier‑side PDP, and asset‑level enforcement. Re‑use ODRL where possible. Keep Zero Trust habits (no implicit trust, continuous verification, least privilege). Bring these patterns into VC agents, wallets, and interop work. DISCLOSURE: We contribute to Catena‑X, Manufacturing‑X, energy data‑X, Chem‑X, and Sphin‑X to help move decentralized identity, trust, and data‑sharing forward for Industry 4.0, Supply Chain, and Critical Infrastructure. @Daniel Hardman: Before you write it, note that there is quite some potential to reduce complexity. It is a good object of study anyway. From: Alan Karp <alanhkarp@gmail.com> Sent: Samstag, 23. August 2025 00:50 To: Bob Wyman <bob@wyman.us> Cc: W3C Credentials CG (Public List) <public-credentials@w3.org> Subject: Re: Access Control You're right. I used the wrong criterion. I should have focused on the hazards rather than the mechanisms. The question I should have asked is if the example introduces a new hazard. Relying on existing mechanisms was a poor way of deciding. Most, if not all, of your examples can be handled by the verifier, the PDP for those of you in the know. Nothing says the verifier can only look at the authentication for ACLs or the certificates for capabilities. It's free to include whatever additional information it needs, such as whether the US is at war with Canada. (That used to be funny.) While the verifier is part of the access control system, Cedar shows it is possible to enforce complex policies without specialized code. That means examples such as blocking certain compositions don't represent new hazards; they just need to be included in the policy. On the other hand, the verifier can't deal with the confused deputy example. It sees a legitimate request from Bob but has no way to know Bob made that request because Alice asked. That makes it a hazard. As your list demonstrates, there's an unbounded set of policies. We certainly don't want to include a specific mechanism in our design for each one of them. Instead, we want our access control system to deal with cases that the verifier may not see, such as delegations, or that can't be expressed as policies, as with the confused deputy. Which of your examples do that? Thanks for the insightful comments, Bob. They've helped me clarify my thinking. -------------- Alan Karp On Fri, Aug 22, 2025 at 1:59 PM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: Alan, You wrote: "The question is whether the policy introduces a new hazard or if it can be enforced with an existing mechanism" I think this constraint (i.e. "enforced with an existing mechanism") needs a bit more elaboration. Isn't delegation largely a convenience which could be enforced with an existing mechanism? It seems to me that the effect of delegation could be provided by having delegatees simply send messages to the object owner, asking the owner to perform the desired actions. (e.g. Instead of Alice delegating to Bob, she could tell Bob to send her a list of commands that Alice would then issue herself and then forward the results to Bob. This "existing mechanism" would be effective, but would be terribly cumbersome.) Similarly, as you suggest, Alice could delegate each day to Bob at the start of Bob's work day and then revoke that delegation at the end of Bob's work day. However, that would require Alice to get to work each day before Bob does and to stay at work until after Bob's work day ends. Of course, if she were the manager of an international organization with hundreds of members, she might be doing dozens of delegations and revocations at every hour of the day, every day. While cumbersome, this is an "existing mechanism" that is technically feasible, although not very practical. Rather than using your somewhat ambiguous definition of policy, I think it might be useful to distinguish between two classes of states or conditions: * Things that can be detected by a machine (i.e. time of day, use of user account, existence of intruder threat, outside temperature, employee database status, etc.) * Things that can only be detected by people, or that rely on judgements made by people. (i.e. personhood, trust, assessed competence, etc.) It seems to me that an ideal access control system would be able to handle an arbitrarily complex set of machine-detectable states and conditions while we have no choice but to insist that only humans do those things that only humans (or their AI proxies?) can do. Now, I'll admit that one might wish to distinguish between an "ideal" access control system and a "practical" or implementable system... But, it is often good to understand the ideal before deciding how much less than ideal is one's goal. bob wyman On Fri, Aug 22, 2025 at 12:52 PM Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com> > wrote: On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: So, if policy determines "how those permissions get assigned," but not the permissions themselves, then I assume that the following use cases would not involve policy: The question is whether the policy introduces a new hazard or if it can be enforced with an existing mechanism. I'm not saying that what I suggest below is the best or even a good way, just that the mechanism can enforce the policy. The "verifier" I talk about below is the component that makes the access decision based on Bob's permissions and his request. After following some written policy guidelines, Alice delegates to Bob, but the delegated permissions she provides are constrained to work: * Only for the two-weeks that she's out on vacation. Alice delegates to Bob before she leaves and revokes when she returns. * Only between the hours of 6pm and 9am during weekdays which are workdays. Alice delegates to Bob at 6 PM and revokes at 9 AM on every work weekday. * Only if Bob has received a complimentary delegation from Dave. (i.e. composition required) Alice asks Dave what he delegated to Bob before she delegates to Bob. * Only if Bob can't compose Alice's delegation with any other delegation. (i.e Bob can't do anything Alice couldn't do.) The verifier can enforce this policy. (This approach is used in consulting firms to implement a Chinese Wall between employees doing work for competing clients.) * Only a maximum of three times Alice tells the verifier to tell her each time Bob uses the permission and revokes after the 3rd use. * Only a maximum of three times during any 24-hour period Ditto * Only while the intrusion detection system is reporting a suspected intruder. The verifier can enforce this rule. (This approach is used in Risk Adaptive Access Control.) * Only when the outside temperature is above 99 degrees. Ditto * Only if Bob's continued employment by Alice's employer can be confirmed. Bob gets permission to invoke Bob-agent, and any delegations are to Bob-agent. You revoke Bob's permission to invoke Bob-agent when he leaves the company. * Only if Bob uses the permissions to manipulate one or more of an enumerated list of objects. The delegation only gives Bob permission to the enumerated list of objects. * etc. I agree that policies like these are important considerations, but do they introduce hazards that I didn't cover? If so, then I should add use cases for them. -------------- Alan Karp On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: So, if policy determines "how those permissions get assigned," but not the permissions themselves, then I assume that the following use cases would not involve policy: After following some written policy guidelines, Alice delegates to Bob, but the delegated permissions she provides are constrained to work: * Only for the two-weeks that she's out on vacation. * Only between the hours of 6pm and 9am during weekdays which are workdays. * Only if Bob has received a complimentary delegation from Dave. (i.e. composition required) * Only if Bob can't compose Alice's delegation with any other delegation. (i.e Bob can't do anything Alice couldn't do.) * Only a maximum of three times * Only a maximum of three times during any 24-hour period * Only while the intrusion detection system is reporting a suspected intruder. * Only when the outside temperature is above 99 degrees. * Only if Bob's continued employment by Alice's employer can be confirmed. * Only if Bob uses the permissions to manipulate one or more of an enumerated list of objects. * etc. bob wyman On Thu, Aug 21, 2025 at 8:34 PM Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com> > wrote: On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: Alan Karp wrote: "Policy is a topic I chose to avoid." How is "policy" distinguished from access control? Policy decides who gets which permissions when. Access control is how those permissions are represented and used. For example, an ACL is an access control mechanism that represents permissions but it says nothing about how those permissions get assigned. -------------- Alan Karp On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: Alan Karp wrote: "Policy is a topic I chose to avoid." How is "policy" distinguished from access control? bob wyman On Thu, Aug 21, 2025 at 5:43 PM Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com> > wrote: On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: When addressing Composed Delegations, you say: Composable: Dave needs to be able to get one permission from Alice, another from Bob and use them both in the same API call. Imagine that Bob and Alice both have Q,U, and D privileges in respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D to Dave. Neither Bob nor Dave I think you mean Alice are aware that the other had delegated privileges to Dave. Now, Dave needs to do something to X that requires both U and D. Are you really comfortable with letting him combine the Q from Alice with the D from Bob? Doing this would allow Dave to do something that neither Bob nor Alice intended him to do. In fact, both Bob and Alice might be very surprised to learn that Dave had, in fact, done that thing. You could also ask if Alice's delegation to Dave violates some policy. Policy is a topic I chose to avoid. If you want policy enforcement, you'll have to mediate delegations in some way. However, you still need to deal with credential sharing to get around blocked delegations. -------------- Alan Karp On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us <mailto:bob@wyman.us> > wrote: When addressing Composed Delegations, you say: Composable: Dave needs to be able to get one permission from Alice, another from Bob and use them both in the same API call. Imagine that Bob and Alice both have Q,U, and D privileges in respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D to Dave. Neither Bob nor Dave are aware that the other had delegated privileges to Dave. Now, Dave needs to do something to X that requires both U and D. Are you really comfortable with letting him combine the Q from Alice with the D from Bob? Doing this would allow Dave to do something that neither Bob nor Alice intended him to do. In fact, both Bob and Alice might be very surprised to learn that Dave had, in fact, done that thing. bob wyman On Thu, Aug 21, 2025 at 1:49 PM Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com> > wrote: I have followed a variety of access control systems off and on for some 30 years, including the recent discussion on this list of the use of OAuth 2.0 and 2.1. I have concluded that many, if not all of them, suffer from being based on use cases that are too simple. In an attempt to address that problem, I've constructed a bunch of use cases <https://alanhkarp.com/UseCases.pdf> that I think capture all the hazards an access control system must address. Comments, criticisms, and corrections will be appreciated and resented in equal measure. -------------- Alan Karp -- Spherity GmbH <https://www.spherity.com/> | Emil-Figge-Straße 80 | 44227 Dortmund LinkedIn <https://www.linkedin.com/company/spherity> | X <https://twitter.com/spherity> | YouTube <https://www.youtube.com/@spherity2407> Managing Directors: Dr. Carsten Stöcker, Dr. Michael Rüther Registered in Dortmund HRB 31566
Received on Saturday, 23 August 2025 13:29:50 UTC