Participant Relationship Protocol

Back to matrix

D04-CG: Yes

Rationale

A concrete local-ownership construction uses an already provisioned user-owned BP node instance. ION documents separate SDR databases/working-memory keys and local directories for multiple instances; bprc adds local endpoint EIDs, and ionsecrc loads locally held named keys. Additional service EIDs under the same provisioned node number, with distinct local BPSec key/policy contexts, can plausibly be created without changing host interfaces or routes. Managing an owned protocol database is distinct from requiring host-network administrator privileges.

Assessment method

Documentary local-identity ownership plausibility; no runtime isolation test

Source context

Pinned ION multi-instance, local endpoint and local key configuration

Outstanding qualification

Keep the provisioned TCPCL/TLS node transport and CGR contact/exit configuration unchanged. Credit local endpoint/service identities and user-held security context only. The user must already own its instance/store and authorized node transport; this does not grant a user control over a shared administrator-owned ION database. Avoid shared default IPC keys and use owned files. Peer trust/key acceptance is separate. Shared symmetric BPSec keys do not prove exclusive asymmetric authorship. Exact BSL key-provider/profile integration and multi-user isolation have not been executed; no full-stack conformance or automatic routing to new node numbers is claimed.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.