Digital Twin KIT, Request for some changes

### Description
I would like to request some changes to the data in the submodel descriptor, because the current status is IMHO unneccessarily restrictive. The current template looks like this:

```json
{
"id": "urn:uuid:e5c96ab5-896a-1234-8761-efd74777ca97",
"idShort": "myAas",
"specificAssetIds": [
{
"name": "manufacturerPartId",
"value": "123-345-567103",
"externalSubjectId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "{{BPN of the party privileged}}"
}
]
}
}
],
"submodelDescriptors": [
{
"id": "e5c96ab5-896a-482c-8761-efd74777ca97",
"semanticId": {
"type": "ExternalReference",
"keys": [
{
"type": "GlobalReference",
"value": "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling"
}
]
},
"endpoints": [
{
"interface": "SUBMODEL-3.0",
"protocolInformation": {
"href": "https://edc.data.plane/mypath/submodel",
"endpointProtocol": "HTTP",
"endpointProtocolVersion": [
"1.1"
],
"subprotocol": "DSP",
"subprotocolBody": "id=123;dspEndpoint=http://edc.control.plane/api/v1/dsp",
"subprotocolBodyEncoding": "plain",
"securityAttributes": [
{
"type": "NONE",
"key": "NONE",
"value": "NONE"
}
]
}
}
]
}
]
}
```
### Request 1: Please make the usage of the asset id in the "subprotocolBody" non-mandatory / optional

As we know, an AAS is typically created and readable for multiple partners. I.e the "specificAssetIds" section contains several entries, but not all of them are meant to be visible for all partners. However, the entries in the "submodelDescriptors" section, are readable for all partners that have any access to this AAS. That means, they would have to be the same for all partners.

Currently, we are required to state an EDC asset Id in the "subprotocolBody" field, that works for all partners. In the explanatory text, it is further stated, that the participants are expected to request the catalog from the control plane via its protocol url. So far so good. But then it is further pointed out, that the participants are expected to filter the catalog for that specific asset id.

My objection with this way of identifying the wanted asset in the catalog is, that it`s too restrictive. As we all know, it is equally possible (and to my best knowledge probably even more common) to filter the catalog for a set of given properties. After all, even the registration of the DTR asset uses a set of properties that allow for the identification of the DTR asset in an EDC catalog, see this excerpt:

```
{
...
"properties": {
"dct:type": {
"@id": "cx-taxo:DigitalTwinRegistry"
},
"cx-common:version": "3.0",
"asset:prop:type": "data.core.digitalTwinRegistry"
},
...
}
```

The point is now, that various submodels (like for instance the ItemStock Submodel) have defined their own set of properties criteria that are currently used to identify them in the EDC catalog. The big advantage of this approach is, that it allows us, to register __one ItemStock Submodel asset per partner__.

Since we are making use of BPNL-restricted policies in our project, this guarantees, that each partner who reqeusts a catalog from a partner's EDC control plane, will only get to see that single asset, that was registered specifically for him, in the catalog he then receives.

Now the real adavantage of that approach is the following: Since we create an ItemStock submodel asset per partner at the EDC, we can assign a partner-specific "baseUrl" within the "DataAddress" field.

This is a great security feature, because it makes it technically impossible that any partner can claim any other BPNL but his own. That means, it is not possible that Partner A with his BPNL1234567890ZZ can send a request to the asset endpoint while claiming that his BPNL is, for instance the BPNL of another Partner B with BPNL0987654321AA.

The EDC policy framework in combination with the MIW are guaranteeing here, that the asset is only reachable for exactly the partner, we want to respond to.

That means, the backend server, that implements and provides the services for the ItemStock submodel can fully trust in the fact, that the sender of a request is no one else but exactly the partner with the BPNL, that is encoded in the baseUrl.

However, this nice and very sensible approach would be made impossible, if we were forced to have only one single asset (with only one single asset id!).

Therefore, I would like to request that the usage of the id that we are required to specify in the AAS in the "subprotocolBody" field is no longer mandatory but optional.

### Request 2: Please make the usage of the "href" field non-mandatory / optional

Currently, the "href" field requires us to specify the public URL of a data plane, where the submodel can be accessed. To be honest, that is in fact not needed. Let us recall, how the access to an EDC asset in general works:

Firstly, we do a request for a catalog via the protocol URL of a specific partner.

Then we pick the asset we want from that catalog. After that, we negotiate for a contract with that partner's control plane, that allows us to access the asset. After the contract is agreed upon by both sides, we can request a transfer. If you are choosing the pull transfer variant (this is what we do here), then we are sent JSON data object, that contains all information we could possibly need. It looks like this:

```
{
"id": "591bb609-1edb-4a6b-babe-50f1eca3e1e9",
"endpoint": "http://localhost:29291/public/",
"authKey": "Authorization",
"authCode": "{{auth-code}}",
"properties": {
"cid": "1:1e47895f-9025-49e1-971d-eb865c38d540"
}
}
```
Example from the [official EDC Samples](https://github.com/eclipse-edc/Samples/blob/main/transfer/transfer-02-consumer-pull/README.md)

As you can see, it contains not only the authKey/authCode data that are needed for authorization of the request at the providing partner's data plane. It also contains the URL, where these credentials can be used.

The thng is: All of these steps need to be executed __anyways__. I.e. we will __always__ have to negotiate for the asset and then request the above mentioned credential data, if we want to access the given asset.

That means, we are always automatically given information about the URL of a data plane public API. So there is simply no need to specify any data plane URL in the "href" field of the submodelDesciptor.

Beyond that, this requirement also sadly ignores the fact, that any partner, who runs an EDC, is free at any time to register additional data plane - instances to his control plane. That means, we always have to account for the possibility, that the data plane URL that is stated in the submodelDescriptor may become outdated, because the owner of the remote EDC control plane had to replace it with a different data plane instance.

My request here in the short term is the fowllowing:
Please make the usage of the data plane URL stated in the "href" field optional, when instead the data plane URL that is received alongside the credential JSON object (see above) is used.