Digital Twin KIT, Request for some changes about eclipse-tractusx.github.io

[matgnt]

Hi @eschrewe
regarding your request number 1:
Would it be an option for you to have the following structure?

1 asset, 2 (or n) policies, 2 (or n) contractdefinitions

With this, you do what is described with 1 asset (or better dataset id) in the subprotocolbody field and depending on who (BPN) looks up the catalog can see (or not) a result, based on what you have configured in the policy.

A contractdefinition basically links 1 asset and 1 policy together that results in an Offer in the Catalog.
That means you can have multiple such policies. Each for every BPN you want to grant access and still use the same asset.

Would this help in your situation?

--
Matthias Binzer

[eschrewe]

Hi @eschrewe regarding your request number 1: Would it be an option for you to have the following structure?

1 asset, 2 (or n) policies, 2 (or n) contractdefinitions

With this, you do what is described with 1 asset (or better dataset id) in the subprotocolbody field and depending on who (BPN) looks up the catalog can see (or not) a result, based on what you have configured in the policy.

A contractdefinition basically links 1 asset and 1 policy together that results in an Offer in the Catalog. That means you can have multiple such policies. Each for every BPN you want to grant access and still use the same asset.

Would this help in your situation?

-- Matthias Binzer

Hi @matgnt ,

thanks for your input. I am aware of the fact, that a single asset can be tied together in a contractdefinition with multiple policy defintions.
What I didn't know however, when I wrote that Issue one week ago was, that the BPNL also gets automatically inserted in the HTTP Header (key: "edc-bpn"), when it is forwarded by the Data plane during a transfer request. But luckily someone hinted me on that a short time later :)
That means, on my backend server I can evaluate that Header entry and I can trust on the fact, that the EDC has confirmed that the sender of that message is indeed the owner of that BPNL. So in fact, there is a proper alternative to the approach that I was describing above.

However, in principle the point, I was trying to make there, still stands:
Is is really neccessary to be restricted to one single asset id, that must be valid for all participants?

I think the details on how a wanted submodel EDC asset is to be identified in the EDC catalog should be made left to be laid out in detail within the respective specifications of each submodel.

Any client, who finds a GlobalReference, that points to a certain submodel (in the example above, for instance: "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling") needs
a) to know what this submodel is all about and why and when he might want to use it,
b) to lookup all further details for proper interactions with that submodel

Both of these things can only be solved by reading the detailed specification of the given submodel anyways. The best thing, the DTR can possibly do is, in my opinion to give a link to the official documentation of the submodels.

[matgnt]

Good to hear you could solve your issue.

Regarding your question

Is is really neccessary to be restricted to one single asset id, that must be valid for all participants?

Well, I guess this can be discussed. As I understand your request, you would additionally allow something like:

"subprotocolBody": "asset:prop:type=data.core.digitalTwinRegistry;dspEndpoint=http://edc.control.plane/api/v1/dsp",

(changed id to asset:prop:type)
for cases when you want to leave it open for the point when you create your EDC assets, right?
Obviously, the result could be multiple datasets (/assets) with additional difficulties to decide which one to use. But still not a blocker.

Right now, I didn't see a use case to require this, but open for input here :-)
In case of the registry and notification systems where we use such properties right now, I would argue that there are NO twins in the registry for those systems and the lookup is done purely via the Dataspace Catalog.

I'm also not a big fan of asset:prop:type because this is a practice coming from EDC as an implementation, but is NOT part of the Dataspace Protocol (DSP) underneath.
And additionally, the query language that is used to search/query such entries from the Catalog is also NOT standardized in the DSP!
(with using the dataset_id, the item can be fetched without query since it is uniquely identified with the id)

[eschrewe]

Hi @matgnt ,

As I understand your request, you would additionally allow something like:

"subprotocolBody": "asset:prop:type=data.core.digitalTwinRegistry;dspEndpoint=http://edc.control.plane/api/v1/dsp",

sorry no, that's not what I'm proposing or requesting. My request is, that the DTR KIT should simply remain neutral on the issue, how an EDC asset (that is offering a submodel service) can or should be identified within an EDC catalog.

All details in this regard should be exclusively described in the respective specification of each submodel.

As I pointed out, anyone who, finds for instance the "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling" submodel within an AAS, needs to lookup and know that submodel's detailed specification anyways in order to make proper use of it.

I'm not a big fan of either of these two ways. But I am raising the question, whether it is wise or neccessary to make one of these ways de facto mandatory.

So in essence, my proposal would look more like this:

"subprotocolBody": "http://edc.control.plane/api/v1/dsp"

Providing the EDC protocol URL, where that specific submodel asset can be obtained, is in general a good idea in my opinion, because it allows for the possibility that the submodel is not registered on the same EDC connector as the DTR's api asset. I.e. the EDC connector which is hosting the DTR, where we got a certain AAS from a partner, does not have to be the same where all the submodel API assets are registered.

On a minor sidenote, I think it's also in general not a good idea to put two different informations in one single JSON-string field, separated only by a semicolon. This makes deserialization more error prone. If both of these informations were equally important, why not give them a separate JSON key each? But that's far besides the point I am making here. In my opinion, the protocol URL alone is sufficient here.

But apart from that, I'd actually be very interested in hearing your thoughts on my other request too, @matgnt :)

[matgnt]

Hi @eschrewe

sorry no, that's not what I'm proposing or requesting. My request is, that the DTR KIT should simply remain neutral on the issue, how an EDC asset (that is offering a submodel service) can or should be identified within an EDC catalog.

All details in this regard should be exclusively described in the respective specification of each submodel.

I think this should be avoided. It kind of delegates the 'logic' even further away from the AAS logic.
AAS and its clients in general don't know anything about a Dataspace protocol and that they need to negotiate a data usage contract first. We in Catena-X make this mandatory, spec-wise by the standards that we publish and technically, by the information "subprotocol": "DSP", so that a client understands what needs to be done.

In what you propose, we would need to further distinguishe the logic, by e.g. introducing "subprotocol": "DSP-materialforrecycling". Which is possible, but I think this delegates logic into too tiny use cases. AAS started with a more higher level concept and we should not go too far away from it.

Providing the EDC protocol URL, where that specific submodel asset can be obtained, is in general a good idea in my opinion, because it allows for the possibility that the submodel is not registered on the same EDC connector as the DTR's api asset. I.e. the EDC connector which is hosting the DTR, where we got a certain AAS from a partner, does not have to be the same where all the submodel API assets are registered.

This is a general topic to discuss. We thought about not doing this, but rather using the BPN here, which goes more into the direction you thought, right?
I personally prefer not to have to many CX specifics in here. The goal is to make this a standard way of connecting AAS and Dataspace protocol. If we would introduce BPNs and consequently the BPN lookup services here as well, there is no chance to get this accepted as a broader standard - and this should be the goal for better interoperability!

On a minor sidenote, I think it's also in general not a good idea to put two different informations in one single JSON-string field, separated only by a semicolon. This makes deserialization more error prone. If both of these informations were equally important, why not give them a separate JSON key each? But that's far besides the point I am making here. In my opinion, the protocol URL alone is sufficient here.

Absolutely agree here! The only reason we did it like that, was the limitation of the AAS standard. Our goal in CX is to be AAS compliant. Separate fields are not supported in AAS, but subprotocol fields is a standardized field and is e.g. used in OPC UA. In the future - I hope - we can integrate more specific fields in the AAS standards to better align the Dataspace Protocol and the AAS - not only for us in CX, but also other Dataspaces to come :-)

But apart from that, I'd actually be very interested in hearing your thoughts on my other request too, @matgnt :)

I just wanted to finish part 1 to not mix too many questions :-)
But since you ask :-)
Short answer: href is mandatory in AAS standards
https://industrialdigitaltwin.org/wp-content/uploads/2023/04/IDTA-01002-3-0_SpecificationAssetAdministrationShell_Part2_API.pdf
(I hope this is the correct link to the latest docs...)

Longer answer: For a client it should be completely invisible whether there is a EDC data plane, or any other API Gateway or an integrated-into-the-AAS-server in place. A Client just fetches the data from what is referenced in the href - as it does in any other AAS use case outside of CX. The only difference in CX is, that we have a special Auth-Token in the Authorization header - which is the result from the Dataspace Transfer process.

Right now, many implementations use the EDC data plane, but in the future, many solutions will implement that token check into existing API gateways or existing AAS Servers. The logic doesn't do much. Just a JWT token check with round about 20-40 lines of code.