[glpatcern]

This PR evolves the Directory Service and makes it distributed, with two models:

• A "peer-announced", eventually consistent model, where nodes notify each other
• A MLS-based model, where membership to a federation is cryptographically guaranteed

In both cases, the concept is that a human administrator decides whether an OCM Server is member of a federation. Injecting a pre-populated list of servers by configuration remains possible.

Technically, two new notifications are now defined, OCM_SERVER_ADDED and OCM_SERVER_REMOVED, which use federation as shareType. This is a deliberate choice so that federation refers both to a group of users spanning multiple servers - managed via MLS - and to a group of servers - managed via direct notification or via MLS.

[glpatcern]

I'd like to resume the discussion/evaluation of this feature. As we stand, there were two concerns for which I'm seeking further comments from @michielbdejong, @MahdiBaghbani and whoever wants to contribute:

1. The server federation uses federation, overloading the term that refers to a federation of groups of people spanning multiple servers. This was deliberate, to underlying the similarity and not to introduce yet another keyword, but I'm fine to change that. What should we use instead? And should we actually extend Notifications to talk about "just anything", not necessarily shareType or resourceType?

2. The full description of the Distributed Directory could be entirely moved to OCM-MLS (if I understood it correctly). I gently disagree with that: the peer-announced model has nothing to do with MLS, therefore I'd keep it on the core spec document. If the concern is that we should stabilize the core spec in view of the Last Call, I'd rather delay the Last Call, also in view of other issues to be settled - such as the call for "security is a MUST".

Finally, I remember @mickenordin suggesting that we do not need (any longer) to expose the list of nodes of the federation as an additional endpoint at /.well-known/ocm, which convinced me on the spot, but I recalled later that upon being added, a node needs to query that endpoint to learn about other peers in the federation, as described in https://github.com/cs3org/OCM-API/pull/417/changes#diff-e489167d8c6e58c297ba70433b6559b2c1105eb761c2ce7a10675801ee539927R798-R814

[sunetfreitag]

During the OCM checkpoint meeting, a question came up how this relates to existing (academic) federation infrastructures and federation groups, such as eduGAIN, REFEDS, MyAccessID, etc. Some research around the topic suggests that OpenID Federation might be the closest match and overlap, and that the relationship and binding should be specified better. In general, an AI review of the PR came up with 8 questions that might need to be considered. I have reviewed them and all seem to be valid points, especially the security relevant questions. If we move to v2.0 with MUST for security related features, we SHOULD NOT introduce a new threat model through the distributed directory service. Here are the review questions, with question 7 addressing the OpenID Federation.

1. Who may announce, and do receivers auto-apply?
In the peer-announced model, can any member send OCM_SERVER_ADDED / OCM_SERVER_REMOVED, or only designated servers? If any member can, trust becomes transitive: one compromised or misconfigured member can inject servers into every peer's list. I'd suggest the spec says receivers MUST only accept these from servers already in their federation view, and SHOULD queue them for local admin approval rather than apply them automatically (consistent with "a human administrator decides").

2. Revocation semantics.
Eventual consistency is fine for additions, but removal is the security-relevant case. What is the expected propagation bound, and what should a server do with a peer it hasn't heard a removal for? This matters for trust-dependent features like must-use-mfa/enforce-mfa. Ordering, replay protection (e.g. a monotonic serial or timestamp per federation) and conflicting add/remove events also need a rule.

3. MLS mode: Authentication Service and Delivery Service.
MLS leaves both to the application. Could the PR state:

• how an MLS credential is bound to an OCM server identity (I assume FQDN + the key published at /.well-known/jwks.json, verified over TLS)?
• who orders Commits (Delivery Service), since that reintroduces some coordination point?
• which members are allowed to commit Add/Remove proposals for the server-federation group?

4. Reusing /notifications and the federation shareType.
Using the share-notification channel and the federation shareType for server-membership events mixes a control-plane function with share semantics. Implementations need to be sure a server-membership event is never processed as a share-related notification. Would a distinct notification category, or at least explicit normative text separating the two meanings of "federation", be cleaner?

5. Relationship to the existing signed JWS list (Appendix C).
Is the JWS list kept as one option (e.g. for bootstrapping a new member) or replaced? How does a new server get its initial view of the federation?

6. Membership carries no metadata or policy.
Both the current and proposed directories only express "listed". It would help to allow optional per-server metadata: operator contact, security-incident contact, policy URL, and claims such as "enforces MFA". Without this, must-use-mfa still depends entirely on out-of-band trust.

7. Possible alternative binding: OpenID Federation.
For R&E deployments, eduGAIN is piloting OpenID Federation alongside SAML. An OpenID Federation binding (an ocm_server entity type with JWKS/endpoints, trust marks for federation membership and MFA) would give hierarchical, partly decentralised trust with short-lived statements for revocation, reusing infrastructure national federations already operate. I'm not suggesting a normative dependency, since OCM must work outside R&E. But keeping the Directory Service abstract enough that this could be added later seems worthwhile.

8. Security considerations.
A short threat-model paragraph covering a malicious member, a stale view after removal, and a split view between peers would make the trade-offs between the two models explicit.

[mickenordin]

One thing which I think is tripping us up, is that we are using "Federation" to mean to different things.

One: A collection of servers that trust each other and have a shared governance structure.

Two: a group distributed across multiple servers

I have a hard time coming up with good terminalogy, but I think we should perhaps reserve the term "Federation" for the first concept. Thus a federation is a collection of servers that are configured in such a way that they trust each other based on a shared governance structure.

For the second concept, we could call it a distributed group,which is contrasted with a local group. That would mean that we remove the shareType federation and introduce a distributed-group shareType or even a mls-group in addition to the user and group. If we want a distinct term perhaps we could introduce cluster or syndicate for this, although it may seem contrived.

For this pr, it would mean that anytime "Federation" is mentioned, it should be in IETF-OCM.md and any time distrubuted-group or what ever we choose for the shareType terminology, it is in IETF-OCM-MLS.md.

What do you think?

[glpatcern]

For this pr, it would mean that anytime "Federation" is mentioned, it should be in IETF-OCM.md and any time distrubuted-group or what ever we choose for the shareType terminology, it is in IETF-OCM-MLS.md.

This makes very much sense to me. After all, the people-related federation was never implemented until now and we are more at ease with breaking with the past. I'm not great at terminology but what about dgroup for the distributed-group term, just to have a single and not too long identifier/const? So shareTypes may be user, group or dgroup (the latter specified by OCM-MLS), and federation is only for servers.

[glpatcern]

Also concerning the AI-generated review we discussed with @sunetfreitag, there are a couple of valid points:

1. Who may announce, and do receivers auto-apply?

Yes, that can trivially be added, but indeed the intended behavior is that there's never an automatic inclusion of peers.

2. Revocation semantics. Eventual consistency is fine for additions, but removal is the security-relevant case.

This is a bit trickier and we have to work on that.

3. MLS mode: Authentication Service and Delivery Service. MLS leaves both to the application.

Same here, let's see with @mickenordin on this.

4. Reusing /notifications and the federation shareType.

OK here the proposal to use dgroup (or something else) would solve this point.

5. Relationship to the existing signed JWS list (Appendix C). Is the JWS list kept as one option (e.g. for bootstrapping a new member) or replaced? How does a new server get its initial view of the federation?

Possibly to be better specified, but a new server gets its initial view from a configured list of servers, and by probing their directories. If the configuration is empty, a new server's federation is made of just itself.

6. Membership carries no metadata or policy. Both the current and proposed directories only express "listed". It would help to allow optional per-server metadata: operator contact, security-incident contact, policy URL, and claims such as "enforces MFA". Without this, must-use-mfa still depends entirely on out-of-band trust.

I'm not sure we want to go that far, I mean the additional metadata IMHO is out of scope for OCM.

7. Possible alternative binding: OpenID Federation. For R&E deployments, eduGAIN is piloting OpenID Federation alongside SAML. An OpenID Federation binding (an ocm_server entity type with JWKS/endpoints, trust marks for federation membership and MFA) would give hierarchical, partly decentralised trust with short-lived statements for revocation, reusing infrastructure national federations already operate. I'm not suggesting a normative dependency, since OCM must work outside R&E. But keeping the Directory Service abstract enough that this could be added later seems worthwhile.

I investigated a bit how the OIDFed works, but as I understand it, it's intrinsically hierarchical, whereas we are trying to propose a peer-to-peer model. On top of that, it seems you can't "remove" members, and removal is based on expiry. So I'm not that sure it would fit our context: as much as it would be great to adopt something existing, we should not bend it beyond reason.

8. Security considerations. A short threat-model paragraph covering a malicious member, a stale view after removal, and a split view between peers would make the trade-offs between the two models explicit.

Noted, to do as well.

[mickenordin]

MLS mode: Authentication Service and Delivery Service. MLS leaves both to the application. Could the PR state:

* how an MLS credential is bound to an OCM server identity (I assume FQDN + the key published at `/.well-known/jwks.json`, verified over TLS)?

* who orders Commits (Delivery Service), since that reintroduces some coordination point?

* which members are allowed to commit Add/Remove proposals for the server-federation group?

This is all fully specified in OCM-MLS, except for the first point, where we would need to introduce a server ocm-address, perhaps that is just the domain without a local part.

The group owning server orders the commits.

The member that are allowed to commit proposals is the server that is the group owning server.