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.

[arnoweiss]

This would transcend the scope of the AAS and the mandate of the IDTA. Discovering generic services (which could also be AAS services) can be done in a entity's DSP catalog or even via a did document that's resolvable just from the participant identifier.

[StenGruener]

@arnoweiss but how to do it without a dataspace? I need some pragmatic solution fo the delivery of catalog information. Is DSP catalog somehow orthogonal to well-known-URIs?

[arnoweiss]

AAS is an interoperability standard for business data. As such, it requires an additional identity and access control layer and that's the dataspace. DSP and DCP provide clients a means not only to discover endpoints (like AAS discovery) but also provide authentication material issued by multiple trust anchors. Only then can the server properly authorize the client.

[StenGruener]

So you say that AAS-infra is not operable without a dataspace by design? There are some use-cases around like ours where delivery of public, type-related catalog data is conserned, e.g., handover documentation and technical specification submodels. As I said, i guess we need some pragmatic solution how to extend our solution step by step.

[arnoweiss]

Assuming authentication isn't required, a simple well-known endpoint would totally suffice. However that entire approach collapses when that assumption doesn't hold true. As soon as the Data Consumer requires, say, OAuth2 client credentials, the Data Provider might as well just include all relevant endpoint information in the email when handing over the credentials.

[sebbader-sap]

@alexgordtop I feel like you are thinking about problems very similar to what is discussed here. Please have a look.