Starting m2m data exchange for one equipment with asset id only

[axenath-pxc]

What is missing?

The initial situration is, that someone just has a physical device with an asset id (, which should be many devices in the future due to IEC61406-01 or -02). The use case could be to make the Digital Product Passport as AAS accessible or other data like available e. g. in incoming goods inspection.

Here the user has a software which can download the AAS, but now he has only the asset Id and no discovery API. One approach could be to get a (a few) general repositories. This could be solved by the approach suggested in #330).

We assume that the data is made available public or a security negotiation is included optionally.

How should it be fixed?

But additionally the way could just lead to the repositories which are relevant for the asset. That is, the response is a list of ass and submodel endpoint for the asset id, e. g. a list of shell descriptors.

In general, and also for the DPP, it might be necessary to open a human-readable web page. Here, we suggest to introduce a new mime-type for the GET when calling the asset id: application/shell-descriptors

[
{
    "assetKind": "Instance",
    "endpoints": [
        {
            "interface": "AAS-1.0",
            "protocolInformation": {
                "href": "https://aasx-server-p2.dev.pxcio.net/shells/aHR0cHM6Ly9pNGQuZGUvVC8xMDQ0MDI0L2Fhcw"
            }
        }
    ],
    "globalAssetId": "https://i4d.de/T/1044024",
    "idShort": "aasT_1044024_FL_SWITCH_2208_PN",
    "id": "https://i4d.de/T/1044024/aas",
    "specificAssetIds": [
        {
            "name": "assetKind",
            "value": "Type",
            "externalSubjectId": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "assetKind"
                    }
                ]
            }
        }
    ],
    "submodelDescriptors": [
        {
            "endpoints": [
                {
                    "interface": "SUBMODEL-1.0",
                    "protocolInformation": {
                        "href": "https://aasx-server-p2.dev.pxcio.net/shells/aHR0cHM6Ly9pNGQuZGUvVC8xMDQ0MDI0L2Fhcw/submodels/aHR0cHM6Ly9pNGQuZGUvVC8xMDQ0MDI0L3N1Ym1vZGVsL05hbWVwbGF0ZQ"
                    }
                }
            ],
            "idShort": "Nameplate",
            "id": "https://i4d.de/T/1044024/submodel/Nameplate",
            "semanticId": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "https://admin-shell.io/zvei/nameplate/2/0/Nameplate"
                    }
                ]
            }
        },
        
}
]

• I have signed the required Developer Certificate of Origin (DCO) already.

[BirgitBoss]

The json example looks like a normal json payload: what exactly is different? Where exactly do you want the new "mime-type" to be added?

If I understand correctly you look for the following interaction:
https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/http-rest-api/interactions.html#fig:seq-sm-endpoints

[axenath-pxc]

Hello Birgit,

The mime-type has to be added to the HTTP GET of the Asset Id, because this is the only information, the client application has in this particular moment.

So the endpoint of the discovery service from https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/http-rest-api/interactions.html#fig:seq-sm-endpoints is unknown to the client application and the interaction does not work. So, I suggest to weaken the following assumption, in some scenarios (asset id is a URL):

Endpoints for infrastructure interfaces like AAS registries are known at design time of the client application or configured manually before start-up.

As the server knows all repositories, he can do the above mentioned interaction also on serverside and return the minimum setup of the dataspace for this particular asset.

Regards
Björn

[sebbader-sap]

I have the feeling that a few things are mixed together in the proposal:

1. Allowing the declaration of different mime-types in the endpoint declaration
2. Knowledge and access (in particular authentication patterns) to infrastructure services, e.g., Discovery Service and AAS Registry
3. Principle knowledge and access (in particular authentication patterns) to AAS endpoints and/or the AAS Repositories.

If we can assume that all endpoints are publicly available, I think the following situation occurs:

1. The client access one (or many) Discovery Services -> result: List of Shell Identifiers
2. The client access one (or many) Registries -> List of ShellDescriptors
3. The client wants to open a website for a specific AAS from that list -> How to find the right endpoint that does not provide only application/json but, e.g., text/html?

[sebbader-sap]

We could expose the non-AAS endpoints maybe like this (note the second item in endpoints):

[
{
    "assetKind": "Instance",
    "endpoints": [
        {
            "interface": "AAS-3.0",
            "protocolInformation": {
                "href": "https://aasx-server-p2.dev.pxcio.net/shells/aHR0cHM6Ly9pNGQuZGUvVC8xMDQ0MDI0L2Fhcw"
            }
        },
        {
            "interface": "text/html",
            "protocolInformation": {
                "href": "https://aasx-server-p2.dev.pxcio.net/shell-website/aHR0cHM6Ly9pNGQuZGUvVC8xMDQ0MDI0L2Fhcw"
            }
        }
    ],
    "globalAssetId": "https://i4d.de/T/1044024",
    "idShort": "aasT_1044024_FL_SWITCH_2208_PN",
    "id": "https://i4d.de/T/1044024/aas",
    "specificAssetIds": [
        {
            "name": "assetKind",
            "value": "Type",
            "externalSubjectId": {
                "type": "ExternalReference",
                "keys": [
                    {
                        "type": "GlobalReference",
                        "value": "assetKind"
                    }
                ]
            }
        }
    ],
    "submodelDescriptors": [...]
}
]

[sebbader-sap]

Schema-wise this would be ok, as Endpoint/interface is only defined as a string. However, I do remember that there were some limitations on what can be used as a value, need to look again. There are more attributes available though, which could be used as well.
For the first endpoint (endpoints[0]), the mime-type is clear as this endpoint is compliant to the AssetAdministrationShellServiceSpecification ("interface": "AAS-3.0") and therefore can only provide application/json.

[sebbader-sap]

What I don't understand right now from the problem description is why the cited assumption needs to be changed. It might be possible to do it also at the runtime of the client application but this would overload the chapter, therefore we put it out of scope...

[BirgitBoss]

Schema-wise this would be ok, as Endpoint/interface is only defined as a string. However, I do remember that there were some limitations on what can be used as a value, need to look again.'

yes, see table https://admin-shell-io.github.io/aas-specs-antora/IDTA-01002/v3.1/specification/interfaces-payload.html
only SUBMODEL-3.0 etc. are allowed so far
The interface attribute is not for mime types.

[arnoweiss]

The mime-type has to be added to the HTTP GET of the Asset Id, because this is the only information, the client application has in this particular moment.

Calling HTTP GET to the assetId is not specified by IDTA-01002-3-0. Since it's a string in the spec, these calls would only succeed in edge cases.

To the feature request in general - starting a discovery process with just an assetId requires one of three options:

1. be aware of some well-known singular entrypoint or
2. be aware of an id that directly resolves to said singular entry point (a did specifically)
3. profile the assetId, define a resolution mechanism and an API specification. Even if this was successful, it would be outside of the AAS specification and not be backward compatible for generic AAS out in the field today.