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.

[seicke]

Maybe RFC9264 (Linkset) could be a technical solution here.
Of course, it should be standardised within the IDTA specs.

[StenGruener]

So this would be the second option is proposed in the issue:

Query on some Identification link URL with a well-defined HTTP Accept header, e.g., application-type/aas-configuration

I am fine with that! How can we specify the content of the link set?

• AAS/SM registry
• AAS/SM repository
• discovery
• probably also some openid realm? I am not an expert here, but we need somehow to indicate to the client application where it can acquire bearer tokens

[alexgordtop]

The request for a standardized way to provide infrastructure endpoints to a data consumer has been a long-standing topic for us as well. My previous considerations have always leaned towards DNS records as a distributed, trusted repository.

However, critics of the DNS-based approach have pointed out that in cases of business unit sales, the original provider would still have to maintain the records in their repositories (at least discovery & registry).

The approach via RFC9264 has the advantage that entire object trees could be redirected to the new owner through a simple HTTP proxy. This would only require a meaningful structure within the GlobalAssetId.

From a security perspective (OAuth2 / OIDC), integrating an identity provider via the OIDC well-known URL would make a lot of sense. I would even go as far as suggesting that individual endpoints (discovery / registry) should document required scopes — this would significantly simplify the process of requesting the appropriate tokens.