Purpose-/scope-list interface

[aw-muc]

Within the current standard the purpose and scope list are a main part of the access control. Is it planned for future implementations to have a standardized interface, where these lists can be queried. This would allow the client to use a standardized interface to react on changes and different versions of the used model or provided scopes?

[UlfBj]

Is it planned for future implementations to have a standardized interface, where these lists can be queried.

This is not in the plans for VISSv2, but could become part of a later version.

These policy documents are owned and controlled by the Ecosystem Owner, so it could be possible for a client to get access via this actor.
I am not convinced that a client should have direct access to these documents.

[aw-muc]

More or less I thought that the server could be a single point of truth, and could also hold that information or maybe a specific interface of the authorization server. The information about the data model of the VISS implementation of the vehicle, should already be known to the developer/app before requesting access. The additional information of available purpose/scope lists of the VISS implementation does not lead to the disclosure of secrets. In the end the user should give his consent to allow the app etc. to request a token with a specific scope/purpose.