From f9111d01368909b5452574db0b621ce8f79ce41b Mon Sep 17 00:00:00 2001 From: Ulf Bjorkengren Date: Fri, 5 Jan 2024 16:52:28 +0100 Subject: [PATCH 1/4] Client-ATS protocol updated to support the consent use case Signed-off-by: Ulf Bjorkengren --- spec/VISSv2_Core.html | 64 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/spec/VISSv2_Core.html b/spec/VISSv2_Core.html index e09ef32..f0f804b 100644 --- a/spec/VISSv2_Core.html +++ b/spec/VISSv2_Core.html @@ -1060,6 +1060,16 @@

Access Grant Response

Access Token Request

+ The client may have to issue several requests before an access token can be obtained, even in the case of having a valid access grant token. + The reason for this is that if a consent is required, the ATS will forward the consent request to the External Consent Framework, + and it is likely that there will not be an immediate response from the ECF. + The ATS will then on the initial access token request respond to the client with a session handle that the client must use in subsequent requests for the access token. + When the ATS has obtained a consent reply from the ECF it can in the thereafter following client inquiry request in the case of a positive consent + respond with the access token, or in the case of a negative consent respond with only the negative consent result. + +

+

Initial Access Token Request

+

The request shall contain at least these two parameters below:

  • Access grant token: A signed token with claims needed for the validation of the @@ -1076,13 +1086,29 @@

    Access Token Request

    making decisions on whether to grant access to the protected resource based on the provided access grant token and purpose.

    +
+
+

Inquiry Access Token Request

+

+ This request can be issued by the client after a session handle has been received in a response to an initial access token request.
+ The request shall contain at least the parameter below: +

    +
  • Session handle: The handle logically links the request to a previously issued initial access token request.
    • +
+

+

Access Token Response

- A successful response shall contain the parameter: + +

+ +
+

Protected Resource Request

From 4655030c17e3e30c9cf0a7570b7d591380914561 Mon Sep 17 00:00:00 2001 From: Ulf Bjorkengren Date: Fri, 5 Jan 2024 17:02:45 +0100 Subject: [PATCH 2/4] Client-ATS protocol cleanup Signed-off-by: Ulf Bjorkengren --- spec/VISSv2_Core.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/VISSv2_Core.html b/spec/VISSv2_Core.html index f0f804b..57db68e 100644 --- a/spec/VISSv2_Core.html +++ b/spec/VISSv2_Core.html @@ -1094,7 +1094,7 @@

Inquiry Access Token Request

This request can be issued by the client after a session handle has been received in a response to an initial access token request.
The request shall contain at least the parameter below:
    -
  • Session handle: The handle logically links the request to a previously issued initial access token request.
    • +
  • Session handle: The handle logically links the request to a previously issued initial access token request.

@@ -1141,7 +1141,7 @@

Access Token Response To Initial Access Token Request

Access Token Response To Inquiry Access Token Request

There are three different responses possible to an inquiry access token request.
- In the case that there is still no consent reply availablefrom the ECF, the response is identical to the response to the initial access token response, see above. + In the case that there is still no consent reply availablefrom the ECF, the response is identical to the response to the initial access token response, see above.
In the case that there is a negative consent reply from the ECF, the response shall contain the parameter:

  • Consent status: The consent reply was negative, so consent status is set to NO.
    • From 45feabf691dd9de90e130f879ba422faa6c5a423 Mon Sep 17 00:00:00 2001 From: Ulf Bjorkengren Date: Mon, 15 Jan 2024 11:57:45 +0100 Subject: [PATCH 3/4] Update according to review. Signed-off-by: Ulf Bjorkengren --- spec/VISSv2_Core.html | 40 +++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/spec/VISSv2_Core.html b/spec/VISSv2_Core.html index 57db68e..79227a4 100644 --- a/spec/VISSv2_Core.html +++ b/spec/VISSv2_Core.html @@ -207,8 +207,10 @@

    Definitions

    Unique id value specified by the client. Returned by the server in the response and used by the client to link the request and response messages. The value MAY be an integer or a Universally Unique Identifier (UUID).
    -
    purpose
    +
    purpose
    A purpose is one of the short text entries from the .
    +
    ECF
    +
    External Consent Framework. An agent that is responsible for inquiring a data owner about consent.
    @@ -1061,10 +1063,10 @@

    Access Grant Response

    Access Token Request

    The client may have to issue several requests before an access token can be obtained, even in the case of having a valid access grant token. - The reason for this is that if a consent is required, the ATS will forward the consent request to the External Consent Framework, - and it is likely that there will not be an immediate response from the ECF. + The reason for this is that if consent is required, the ATS will forward the consent request to the External Consent Framework, + and it is likely that there will not be an immediate response from the ECF. The ATS will then on the initial access token request respond to the client with a session handle that the client must use in subsequent requests for the access token. - When the ATS has obtained a consent reply from the ECF it can in the thereafter following client inquiry request in the case of a positive consent + When the ATS has obtained a consent reply from the ECF it can thereafter following client inquiry request in the case of a positive consent respond with the access token, or in the case of a negative consent respond with only the negative consent result.

    @@ -1132,7 +1134,7 @@

    Access Token Response To Initial Access Token Request

    an immediate response is not possible, and the response to an initial access token request shall contain the parameter:
    • Session handle: A reference to the initial access token request that can be used by the client in subsequent inquiry requests.
      • -
    • Consent status: There is at this point not any consent status eceived from the EF, so consent status is set to NOT_SET.
      • +
    • Consent status: There is at this point not any consent status received from the ECF, so consent status is set to NOT_SET.

    @@ -1141,12 +1143,12 @@

    Access Token Response To Initial Access Token Request

    Access Token Response To Inquiry Access Token Request

    There are three different responses possible to an inquiry access token request.
    - In the case that there is still no consent reply availablefrom the ECF, the response is identical to the response to the initial access token response, see above.
    - In the case that there is a negative consent reply from the ECF, the response shall contain the parameter: + In the case that there is still no consent reply available from the ECF, the response is identical to the response to the initial access token response, see above.
    + In the case that there is a negative consent reply from the ECF, the response shall contain the parameter:

    • Consent status: The consent reply was negative, so consent status is set to NO.
    - In the case that there is a positive consent reply from the ECF, the response shall contain the parameters: + In the case that there is a positive consent reply from the ECF, the response shall contain the parameters:
    • Access token: The token to be used in client requests to the VISSv2 server for Protected Resources.
      • @@ -1800,40 +1802,40 @@

      Consent support

      Handling of consent involves vehicle and cloud architectural subsystems that is out of scope in VISSv2. However, a VISSv2 vehicle server has a capability to enforce consent results, i. e. to allow or block access to requested data. - This can be leveraged in a model where the server receives consent results from an “External Consent Framework” (ECF) and uses that information to either grant client requests, - or not, for data that is consent protected. How the ECF obtains the consent status is out-of-scope in this specification. - A secure, local communication channel exists between the in-vehicle ECF and the server as shown in the figure below, + This can be leveraged in a model where the server receives consent results from an ECF and uses that information to either grant client requests, + or not, for data that is consent protected. How the ECF obtains the consent status is out-of-scope in this specification. + A secure, local communication channel exists between the in-vehicle ECF and the server as shown in the figure below, over which the server can inquire about the consent status for data requested by a client.

      - The ECF is responsible for the lifetime management of the consent status for all data that is managed by the server, which may involve initialization, + The ECF is responsible for the lifetime management of the consent status for all data that is managed by the server, which may involve initialization, event based update, consent status removal.
      The consent status can be set to any of the following values:
        -
      • NOT_SET // the server must request the ECF for the status. Unless an immediate ECF response is given, +
      • NOT_SET // the server must request the ECF for the status. Unless an immediate ECF response is given, the server must deny any client request with an error code that shows the reason.
      • NO // the server must deny any client request with an error code that shows the reason.
      • IN_VEHICLE // the server shall serve the client request. The client is not allowed to off-board the data.
      • YES // the server shall serve the client request. The client is allowed to off-board the data.
      - It shall be possible for the ECF to cancel a valid consent, which shall lead to the consent status being set to NOT_SET. + It shall be possible for the ECF to cancel a valid consent, which shall lead to the consent status being set to NOT_SET. Any consequences to the data provided to the client prior to the cancelling is out of scope.
      In the case of a client request requiring a consent for data to be returned, it is the responsibility of the - access token server to obtain it from the ECF during the dialogue with a client requesting an access token. - This is done by issuing a request to the ECF which shall contain the following information: + access token server to obtain it from the ECF during the dialogue with a client requesting an access token. + This is done by issuing a request to the ECF which shall contain the following information:
      • The requested data.
      • The purpose of the request.
      • The client context.
      - The response from the ECF shall contain: + The response from the ECF shall contain:
      • Consent status.
      If the received consent status is set to NO or NOT_SET, then the access token server must not provide a valid access token to the requesting client. - The server must store the consent status that it receives from the ECF, together with the data from the request for the duration of the associated service, + The server must store the consent status that it receives from the ECF, together with the data from the request for the duration of the associated service, or until a consent cancellation is received.
      Whether a server shall take action to obtain a consent or not shall be signalled in the VSS tree. This is done by tagging appropriate nodes in the VSS tree extending the model used for access control selection. @@ -1847,7 +1849,7 @@

      Consent support