Configuration-API similar to OpenID (aka discovery of discovery)

[StenGruener]

What is missing?

In a use-case of docmentation handover we need to deliver AAS of a device by a pure knowledge of the AssetID (Identification Link). Delivering of AASX package is possible by using some HTTP Accept header. However, for Type 2 AAS we need some covert-channel knowledge of at least

• AAS discovery interface
• AAS registry interface
• SM registry interface

How should it be fixed?

One solution to fix it wolud be the delivery of a "self-contained" aas-descriptor (not in scope of this issue).

What I would like to propose here, is something simliar to OpenID discovery, e.g., https://accounts.google.com/.well-known/openid-configuration.

Thus would be defining some JSON Schema which would contain endpoints which are needed for AAS-discovery procedure, for example:

{
"aas_discovery": <URL>,
"aas_registry": <URL>,
"sm_registry": <URL>, //maybe an array of registries
...
}

and a way to get this JSON-objects

• \<domain-name>/.well-known/aas-configration
• Query on some Identification link URL with a well-defined HTTP Accept header, e.g., application-type/aas-configuration

[BirgitBoss]

Thanks for the proposal. So far we did not define any "interface discovery" or "profile discovery" interfaces for the AAS.

These kind of services are needed, you are right.

In dataspaces like Catena-X the dataspace connector is used for finding the services. A central service is available to find the connectors in the first place.

[axenath-pxc]

Please consider to register this endpoint pattern at IANA (https://www.iana.org/)

See for the above-mentioned openid here: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

The endpoint could be registered then by IDTA as an organization, too.