- The request shall contain the Context and Proof parameters below, the other two are optional:
+ The request shall contain the Context and Proof parameters below, the others are optional:
VIN: The vehicle identification number. Instead of the
assigned VIN a generated hash can be used as a pseudo VIN,
@@ -1024,7 +1024,7 @@
Access Grant Request
The protocol may involve also third parties, such as the ecosystem manager or the
resource owner. The protocol is out of scope for this specification.
In scenarios where both the client and the access grant token server
- are deployed in-vehicle the VIN parameter may be omitted, in all other deployment scenarios it shall be present.
+ are deployed in-vehicle the VIN parameter may be omitted, in all other deployment scenarios it shall be present.
@@ -1129,7 +1129,7 @@
Client
The device. It is in charge of running the Apps that make requests to the VISSv2 server
-
+
All the information regarding the client is encoded in the context of the request.
@@ -1403,7 +1403,7 @@
Short Term Access Grant Token
access grant token server.
The issued at (iat) claim shall be set to the time of token issuance, in Unix time.
The expiry (exp) claim shall be set to the time when the token expires, in Unix time.
- The Client context (clx) claim shall be set to the role triplet the client has been assigned.
+ The Client context (clx) claim shall be set to the role triplet that the client has been assigned.
The delimiter separating the roles is a plus sign (+).
The audience (aud) claim shall be set to the URL "w3.org/VISSv2".
The JSON Web Token identity (jti) claim shall be set to a UUID that is unique within the domain controlled by the
@@ -1437,7 +1437,7 @@
Long Term Access Grant Token
access grant token server.
The issued at (iat) claim shall be set to the time of token issuance, in Unix time.
The expiry (exp) claim shall be set to the time when the token expires, in Unix time.
- The Client context (clx) claim shall be set to the role triplet the client has been assigned.
+ The Client context (clx) claim shall be set to the role triplet that the client has been assigned.
The delimiter separating the roles is a plus sign (+).
The public key (pub) claim shall be set to the public key that the client provided in the
access grant request, using the JSON Web Key (JWK) data structure [[RFC7517]].
@@ -1481,7 +1481,7 @@
Access Token
Each signal is defined as a JSON object containing the signal path, and the signal permission as shown below.
{"path":"vss-path", "access_permission":"permission"}
If the scope claim is set to a purpose, the client context claim MUST be present in the token.
- The Client context (clx) claim shall be set to the role triplet the client has been assigned.
+ The Client context (clx) claim shall be set to the role triplet that the client has been assigned.
The delimiter separating the roles is a plus sign (+).
The audience (aud) claim shall be set to the URL "w3.org/VISSv2".
The JSON Web Token identity (jti) claim shall be set to an unguessable UUID that is unique within the domain controlled by the
@@ -1531,7 +1531,7 @@
Proof of Possession
Client Context
This section is non-normative.
- The client actor is characterized by three subactors:
+ The client context contains a client actor that is characterized by three subactors:
There is also a long purpose description, which may be used in the dialogue for consent, if needed.
Then there is a list of the client context, i. e. the sub-actor role triplet,
that can be granted this access, and last there is a list of the signals that the client is given access to for this purpose,
- with the allowed access permission. The list shall use a JSON format as shown in the example below.
+ with the access control and consent requirements. The list shall use a JSON format as shown in the example below.
+ 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,
+ over which the server can inquire about the consent status for data requested by a client.
+
+
+ Consent architecture.
+
+ 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,
+ expiry update, event based update, consent status removal.
+ The consent status that the ECF provides to the server is associated with an expiry time, which when reached leads to that the status shall be treated as NOT_SET,
+ which must be enforced by the server.
+ 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,
+ 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.
+
+ Regardless of the value of the consent status, if the associated expiry time is exceeded, the server shall treat the consent status as if it had the value 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.
+ The expiry time shall have the timestamp format defined in chapter 5.3 Timestamps.
+ 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:
+
+
The requested data.
+
The purpose of the request.
+
The client context.
+
+ The response from the ECF shall contain:
+
+
Consent status.
+
Expiry time of the consent.
+
+ 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 set by the expiry time.
+ 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.
+ The key-value pair used for tagging of access control is suffixed with "+consent" as shown in the example below:
+
+
"validate":"read-write+consent"
+
+ The consent tagging follows the same inheritance rules as defined for the access control tagging.
+
+
+
+
External Consent Framework Interface
+
+ A server receiving a client request that involves obtaining a consent status shall send a request to the ECF
+ on which it shall receive a response cintaining the consent status.
+
+ The request shall contain the data from the list in the previous chapter.
+
+ The response shall contain the following data:
+
+
The consent status.
+
The expiry time of the consent status.
+
+ This communication shall be carried out using a secure channel (e.g. TLS).
+
+
+
+
diff --git a/spec/images/consent-architecture.jpg b/spec/images/consent-architecture.jpg
new file mode 100644
index 0000000..9b9d095
Binary files /dev/null and b/spec/images/consent-architecture.jpg differ
+