Signing of agreements with participant ID and or DID?

[matgnt]

I'm reading the documentation and saw this description here:
https://github.com/eclipse-tractusx/ssi-docu/blob/3e04aed1b24bf97104f3a46838e82c8635824f96/docs/architecture/cx-3-2/edc/identity.next.md?plain=1#L38C44-L38C44

In this scheme it is possible for a participant to change its DID without altering its stable identifier. For example, a
participant may opt to change its hosting environment, resulting in a change to its DID such as the URL associated with
its DID in the case of `did:web` or its DID method. Since its BPN remains stable, existing signed contracts will not be
impacted.

Can you explain a bit more in detail how this is planned? To my understanding, the BPN itself doesn't have a private key that can be used for signing the agreement, right? So in case of the DID being changed (as described here) also the private key is very likely to change (e.g. move from hosted wallet to a local wallet) and also the lookup of the associated signing key on the agreement would probably no longer return the public key to verify the agreement signature.

Thanks,

--
Matthias Binzer

[jimmarino]

Yes, the plan is to use the credential offer flow for re-issuance as defined here. This would require the contract agreement "signature" for each party to be a VC. This can be done by creating an overlay specification for the DSP or (at some point) defining contract signatures as an optional item in the DSP specifications.

If the DIDs were rotated, the BPN and new Membership Credential would establish the forward linkage to the new DID.

[matgnt]

Hi Jim, thanks for the details.
I think re-issuance is the key word that is missing in the quoted text above.

But still, I wonder how signatures are verified then, as also stated in the text:

Since its BPN remains stable, existing signed contracts will not be impacted.

signed indicates that there will be a real signature on those contracts. There are no signatures on those contracts right now, but I did assume in the future, right? The question is, with what keys are those contracts signed? A BPN doesn't have one. The key from the DID is not there anymore to verify - at least not with did:web because there is no history of key changes. And the text even says, that it was possible to change did methods as well with the concept. Verifying 'old' contract signatures in such cases sounds difficult to me.