How to acces Asset Metadata in code?

[3rim]

Hello,

I implemented my own DataFlowController. Is there a way to acces the Metadata like public properties of an Asset in the DataFlowController?

{
  "@context": {
    "@vocab": "[https://w3id.org/edc/v0.0.1/ns/"](https://w3id.org/edc/v0.0.1/ns/%22)
  },
  "@id": "asb-asset",
  "properties": {
    "key": "i want to acces this value"
  },
  "privateProperties": {
    "privateKey": "value"
  },
  "dataAddress": {
    "type": "AzureServiceBus",
    "azure-servicebus.servers": "adress here"
  }
}

[paullatzelsperger]

@3rim Assets are concepts of the control-plane, they do not in the data plane, other than collecting available transfer types for them.
DataFlowControllers are only responsible for handling, well, the data flow, i.e. start-stop-pause. To me this smells a bit, TBH. What is your use case for this is? What are you trying to do?

[3rim]

Thanks for the fast response.
What we are trying to solve is this.

The provider connector should send, on request from the consumer, a generated credential token for a message broker. The token has an expiry which we want to declare in the Asset and than later use for generating the token.

[paullatzelsperger]

Assets should only contain metadata about the data, and never anything pertaining to token generation, etc.
In addition, the DataFlowController is the wrong place to do this, because it lives in the control plane and talks to the data plane via the Dataplane Signaling Protocol.
Token validation and -rotation etc. should be handled in the data plane. Please take a look at the DataPlaneAuthorizationService, its implementation and related collaborator services. The best way to implement token rotation is to implement a custom variant of the DataPlaneAccessTokenService. This is how Tractus-X has done it.

Also, the token expiry duration should be a configuration value of your dataplane, because its probably the same for all assets transmitted via one particular transmission channel.

[3rim]

Thank you. I think i get a better understanding now.

Let me grasp my previous words again. Basicly we followed the example in the samples folder KafkaBroker.

After a successfull negotiation the provider just should send the generated credentials/token to the consumer so the consumer can connect to the broker. Like in the example we also generate a DataAdress and add ENDPOINT, AUTH_CODE etc. The DataAdress contains the generated acces token. The token expiry is currently hardcoded. Maybe we need to rethink the expiry stuff...

Should we still use your suggestion?

[paullatzelsperger]

In the Kafka example, the consumer ("alice") uses a client secret rather than a short-lived token. However, if "alice" were to use a token instead, then Kafka would be responsible for its renewal (IDK if Kafka offers that, TBH).
The key aspect is that it is always the data plane that is responsible for authentication, and in the sample, Kafka is the dataplane.v

However, in the scenario you describe, you seem to have token rotation implemented manually, so you will need to implement a custom data plane, even if that delegates down to another message broker system.

TL;DR: yes, you should follow my advice.

[3rim]

Ok. Thank you