AAS Server Self Identification

[mrentsch65]

What is missing?

There is currently no standardized means defined for self identification of the AAS server backend a client is talking to.

How should it be fixed?

I propose an enhancement for Part 2, that allows a client to retrieve information about the server it is talking to. There are different ways possible to solve this, i.e.

1. a short response dataobject containing a version-id and a server-selfdescription that is returned on a GET-request on the root.
2. Formulating a requirement towards AAS-Server installations to provide an AAS for itself, containing the SM "Digital Nameplate for Software in Manufacturing".

[BirgitBoss]

There is already a self-description API: https://industrialdigitaltwin.io/aas-specifications/IDTA-01002/v3.1/specification/interfaces.html#GetSelfDescription. It is part of ever service specification.
So probably you think of extensions of the API operation?

[mrentsch65]

Yes, some definition of a standardized and mandatory response object to that API request would likely solve it. What do you think about the idea of returning a "Digital Nameplate for Software in Manufacturing" that tells the client to whom it is talking to?

[mjacoby]

The return payload of the GetSelfDescription API call is already standardized and contains a list of ServiceSpecificationProfileEnum describing the capabilities of the server.

What benefit do you see in returning a Digital Nameplate for Software in Manufacturing over the current solution?

Personally, I think the identity (given via the URL we are calling) and the capabilities should be all the information needed. In contrary, exposing details about the software the server is running as it is included in the digital nameplate is a security risk as it might provide insights about vulnerabilities. This kind of information should typically hidden from a user.

[mrentsch65]

Isn't it quite normal for software to have an "About"-Dialog to tell the user on which version he is operating?
It is of course still under control of the AAS service provider which information he wants to share in their API response. And insight information should only be given to authorized users.

Unfortunately, these ServiceSpecificationProfileEnum don't provide much useful information for an audit trail. How can I find out the details behind them without doing a research project?

[mjacoby]

For GUI applications this is typical, yes. Also for servers it is typical but for servers this information is typically reserved for the admin as users might use such information for targeted attacks.
In our implementation (FA³ST) for example, we print the version of the software used in the command-line output and log when starting a server. There is also nothing stopping server from exposing this information in any other way they want, e.g. via REST.

It might be possible to safely expose this information if it is only accessible to certain authorized users however, to my knowledge, this could not be defined in such a way in the specification as I think there are no definitions as roles such as "admin" (but I am not an expert on security/part 4).

Unfortunately, these ServiceSpecificationProfileEnum don't provide much useful information for an audit trail. How can I find out the details behind them without doing a research project?

What do you mean by details behind them? The returned values are Profiles, i.e., a fixed set of operations/API calls that the server supports, as defined in the specification. However, it does not include details about the implementation of the server but only about the publicly exposed API.

[arnoweiss]

Agree with mjacoby.

• spec version is exposed via the GetSelfDescription endpoint
• software version is implementation specific. Exposing it via API would be a bad idea as it could label deployments as exploitable in case certain patches are known but not yet applied.

[mrentsch65]

• software version is implementation specific. Exposing it via API would be a bad idea as it could label deployments as exploitable in case certain patches are known but not yet applied.

Security by obscurity? This is is not really working.
The solution would be a matter of balancing between transparency, usability, and security.

An established best practice would be a) Hide Version Information by Default, b) Expose Only When Necessary and c) Monitoring:

If version info is required (as in this case for frontend developers and troubleshooting), it could only be exposed in controlled ways, such as an authenticated endpoint. And of course monitoring on the backend side for unauthorized scans should be recommended anyway.

I believe all these points have already been made in the thread above.

[arnoweiss]

You used to see nginx deployments on the web that expose their versions a lot until there was a collective realization that this is a bad, bad idea. The AAS community shouldn't make that mistake itself.

If you need, expose the version of your application on internal APIs. For examples, with Eclipse Basyx, you can expose the Spring-native /acutator/info endpoint. But this is information doesn't belong on the public internet or you'll act just as irresponsibly as Cariad.