ISO 20078-3:2021
(Main)Road vehicles — Extended vehicle (ExVe) web services — Part 3: Security
Road vehicles — Extended vehicle (ExVe) web services — Part 3: Security
This document defines how to authenticate users and accessing parties on a web-services interface. It also defines how a resource owner can delegate access to its resources to an accessing party. Within this context, this document also defines the necessary roles and required separation of duties between these in order to fulfil requirements stated on security, data privacy and data protection. All conditions and dependencies of the roles are defined towards a reference implementation using OAuth 2.0 compatible framework and OpenID Connect 1.0 compatible framework.
Véhicules routiers — Web services du véhicule étendu (ExVe) — Partie 3: Sécurité
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 20078-3
Second edition
2021-11
Road vehicles — Extended vehicle
(ExVe) web services —
Part 3:
Security
Véhicules routiers — Web services du véhicule étendu (ExVe) —
Partie 3: Sécurité
Reference number
ISO 20078-3:2021(E)
© ISO 2021
---------------------- Page: 1 ----------------------
ISO 20078-3:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 20078-3:2021(E)
Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 2
4.1 Processes . 2
4.2 Conditions . 2
5 Basic communication flow. 3
5.1 Offering party authorization domain . 3
5.1.1 General . 3
5.1.2 Authentication . 3
5.1.3 Authorization . 4
5.1.4 Resource access . 6
5.1.5 Separation of duties . 7
5.1.6 Implementation related considerations . 9
5.2 Accessing party authorization domain . 11
5.2.1 General . 11
5.2.2 Authorization . 11
5.2.3 Pushing resources .12
Annex A (informative) Reference implementation using OAuth 2.0 and OpenID Connect 1.0 .13
Annex B (informative) Reference implementation for push .21
Bibliography .24
iii
© ISO 2021 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 20078-3:2021(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 20078-3:2019), which has been
technically revised.
The main changes are as follows:
— defined authorization domains for the offering party and the accessing party;
— added new requirements and description related to push method to make the offering party
authorized to push resources to the accessing party;
— added Annex B containing description of reference implementation for push.
A list of all parts in the ISO 20078 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
© ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD ISO 20078-3:2021(E)
Road vehicles — Extended vehicle (ExVe) web services —
Part 3:
Security
1 Scope
This document defines how to authenticate users and accessing parties on a web-services interface. It
also defines how a resource owner can delegate access to its resources to an accessing party. Within
this context, this document also defines the necessary roles and required separation of duties between
these in order to fulfil requirements stated on security, data privacy and data protection.
All conditions and dependencies of the roles are defined towards a reference implementation using
[1] [2]
OAuth 2.0 compatible framework and OpenID Connect 1.0 compatible framework.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 20078-1, Road vehicles — Extended vehicle (ExVe) web services — Content and definitions
3 Terms and definitions
For the purposes of this document, the convention, terms and definitions given in ISO 20078-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
identity token
ID token
digitally signed JWT and contains claims (3.3) about the authenticated resource owner
3.2
authorization code
intermediate result of a successful resource-owner authorization process and that is used by authorized
clients to obtain access tokens and optionally refresh tokens
3.3
claim
asserted information about a certain entity
EXAMPLE ROID, resource owner’s first name, last name, address, connected vehicle’s capability and/or
other attributes.
3.4
token issuer
entity that generates and provides identity tokens (3.1), access tokens, and refresh tokens
1
© ISO 2021 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 20078-3:2021(E)
3.5
authorization domain
domain of activity where an entity controls the authorization
Note 1 to entry: The offering party controls the authorization in the offering-party authorization domain and the
accessing party controls the authorization in the accessing-party authorization domain.
Note 2 to entry: Due to the description of push communication in 5.2 there exists two different authorization
providers. One at the side of the accessing party and one at the side of the offering party.
4 General
4.1 Processes
The following processes are specific to each offering party. The definition of these processes is not part
of this document but shall be in place in order to apply this specification.
REQ_04_01_01 The process to register a resource owner at the identity provider shall be the re-
sponsibility of the offering party.
REQ_04_01_02 The process to register an accessing party at the authorization provider shall be the
responsibility of the offering party.
REQ_04_01_03 The process to confirm the technical eligibility of connected vehicles and provision
of their associated ExVe resources shall be the responsibility of the offering party.
REQ_04_01_04 The process to verify a resource owner’s current and valid ownership of the con-
cerned resource shall be the responsibility of the offering party.
REQ_04_01_05 The process to register the offering party in the accessing party authorization domain
shall be the responsibility of the accessing party. This is only needed if resources
shall be pushed.
4.2 Conditions
REQ_04_02_05 The offering party shall be able to restrict or deny the accessing party and/or the
resource owner access to the offering party’s web services and portals.
NOTE 1 This can be done, for example, to fulfil security and legislation requirements.
REQ_04_02_06 If the offering party revokes a granted registration of an accessing party, the offering
party may delete all containers created by the accessing party, if containers are used.
NOTE 2 Revocation of the registration can be due to access violation or other misuse of the web services.
REQ_04_02_07 The accessing party shall be able to restrict or deny the offering party’s ability to
push resources.
NOTE 3 This can be done, for example, to fulfil security and legislation requirements.
2
© ISO 2021 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 20078-3:2021(E)
5 Basic communication flow
5.1 Offering party authorization domain
5.1.1 General
This document separates the activities necessary for authentication, authorization and resource access
into three distinct communication flows with separate duties (see Figure 1).
a
Step 1: the resource owner is authenticated by the identity provider.
b
Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization
provider.
c
Step 3: the accessing party is accessing resources from the resource provider.
Figure 1 — The roles and the three distinct communication flows
5.1.2 Authentication
The identity provider is responsible for authenticating the resource owner and managing the resource
owner profile, based on the resource owner registration. The resource owner credentials are revealed
only to the identity provider, and the identity provider confirms a successful authentication to
concerned parties. If the resource owner has given consent, the accessing party will be authorized to
access the resource owner's profile (Figure 2).
3
© ISO 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 20078-3:2021(E)
Figure 2 — Resource owner authentication and access to resource owner’s profile
REQ_05_01_01 The identity provider shall offer a suitable authentication method and shall perform
the authentication process. After a successful authentication, the identity provider
shall confirm the identity of the authenticated resource owner.
REQ_05_01_02 The resource owner’s credentials shall only need to be known by the resource owner
and be possible to be verified by the identity provider.
REQ_05_01_03 The resource owner’s registration and authentication (at the identity provider), shall
be separated from the authorization process to grant access to resources (via the
authorization provider).
REQ_05_01_04 If the identity provider is able to expose the resource owner’s profile to the accessing
party, it is only the resource owner that shall be able to grant or deny access.
5.1.3 Authorization
The client application as a component of the accessing party requires access to resources on behalf of
the resource owner. At the authorization step, the accessing party requests authorization to access the
resources provided by the resource provider (offering party). The required authorization is requested
at the authorization provider, providing the intended scope. By the consent of the resource owner, the
authorization provider returns a limited authorization to the client application of the accessing party.
Using the obtained authorization, the client application can access resources. authorization to access
resources is done in the same way regardless, if the resources are fetched by the accessing party using
request/reply or pushed by the offering party (see Figure 3). See ISO 20078-2 for details regarding
request/reply and push.
4
© ISO 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 20078-3:2021(E)
Figure 3 — Requesting access to resources
REQ_05_01_05 Before accessing the resource, the accessing party shall request access at the au-
thorization provider providing the intended scope.
REQ_05_01_06 The authorization provider shall be responsible for the management of the author-
ization policy and shall manage all granted accesses.
NOTE 1 The authorization policy, for example, defines the permissions of the accessing party, primarily the
conditions to be met for granted access to resources.
REQ_05_01_07 The authorization provider shall trust the confirmation of successful authentication
as provided by the identity provider.
REQ_05_01_08 The authorization policy shall be defined by the offering party concerning the au-
thorization process.
REQ_05_01_09 The authorization provider shall be able to verify the relationship between resource
owners and their resources.
REQ_05_01_10 Only the resource owner shall be able to grant access to a resource.
NOTE 2 The access is granted to an accessing party at the offering party.
REQ_05_01_11 Granting access to resources shall be done either directly or via containers. The
offering party decides if one or both of the granting methods shall be provided to
the accessing parties.
5
© ISO 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 20078-3:2021(E)
REQ_05_01_12 The resource owner shall be able to revoke a granted access to a resource at any time.
REQ_05_01_13 If containers are used, the resource owner shall be able to revoke a granted access
to a containers at any time.
REQ_05_01_14 The authorization provider shall ask the resource owner for the approval before
providing the authorization to the accessing party resulting in a granted access.
REQ_05_01_15 Upon request the offering party shall present a resource owner’s granted accesses
to the resource owner.
REQ_05_01_16 The resource owner shall be able to deny an access request to a resource, or if con-
tainers are used, to a container at any time.
REQ_05_01_17 If the ownership of a resource or the relationship between the resource owner and
the resource ends, access to the corresponding resources, and if containers are used,
also to containers, shall be revoked.
REQ_05_01_18 If containers are used and if a container is deleted, all access granted to that con-
tainer shall be revoked.
5.1.4 Resource access
Using the access, the accessing party can access the resources, hosted by the resource provider (see
Figure 4).
Figure 4 — Access to resources via the resource provider
REQ_05_01_19 The resource provider shall perform access control to the resources according to
the authorization policy.
6
© ISO 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 20078-3:2021(E)
5.1.5 Separation of duties
Separation of duties concerns the separation of tasks and responsibilities between entities involved in
the authentication, authorization and access to resources.
Figure 5 — Separation of duties between involved roles
Figure 5 describes the separation of duties between involved roles, where the offering party has the
three roles: identity provider, authorization provider, and resource provider.
REQ_05_01_20 The identity provider shall not be dependent on the authorization policy.
REQ_05_01_21 The identity provider shall not influence the authorization policy.
REQ_05_01_22 The identity provider shall not access the resources.
REQ_05_01_23 The authorization provider shall not access the resource owner profile.
REQ_05_01_24 The authorization provider shall only use the unique ResourceOwnerID to identify
the resource owner.
7
© ISO 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 20078-3:2021(E)
NOTE 1 The ResourceOwnerID is generated and communicated by the trusted identity provider.
REQ_05_01_25 The authorization provider shall not have access to resources provided by the re-
source provider.
REQ_05_01_26 The resource provider shall not access the resource owner profile.
REQ_05_01_27 The resource provider shall not know details about the authorization process.
REQ_05_01_28 The resource provider trusts the authorization provider and shall verify whether the
provided authorization matches the access control rules defined for the requested
resources.
REQ_05_01_29 The resource owner shall not need to share credentials with the accessing party to
enable the accessing party to access the resources.
REQ_05_01_30 The accessing party shall only access the resources with the consent of the resource
owner.
NOTE 2 The requirements stated above do not impose requirements on specific architecture, design or
organizational structure.
Figure 6 shows the major logical components of the involved roles and the associated entities.
8
© ISO 2021 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 20078-3:2021(E)
Figure 6 — Involved roles and associated entities
5.1.6 Implementation related considerations
The physical implementation and assignment of roles to real parties differs from the logical
representation as shown in Figure 6, and follows the defined requirements as referenced by Figure 7.
9
© ISO 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 20078-3:2021(E)
Figure 7 — Logical representation of involved roles and their entities
in reference to the defined requirements
Additionally, actual implementation often depends on national legal requirements (e.g. handling of
resource owner profile, implemented resource owner’s verification process etc.) and the required
trusted relationship between involved components especially identity provider, authorization provider,
and resource provider.
REQ_05_01_31 All communication paths between involved entities shall use secured connections.
REQ_05_01_32 The identity provider, authorization provider, and resource provider are responsible
for ensuring that only recent cipher suites are used.
NOTE 1 Changes in the interface are communicated to accessing parties within a reasonable notice period.
If the offering party encounters an unreliable accessing party, the offering party can temporarily or
permanently revoke the accessing party’s access. This is done in order to protect the resource owners.
Examples of circumstances that could trigger this are: insecure smartphone applications, disabled
host verification, data breach of database, forbidden caching or storage of resource data, usage of
discouraged security algorithms.
REQ_05_01_33 It shall be possible to validate the authenticity and integrity of information provided
by the identity provider, authorization provider and resource provider.
10
© ISO 2021 – All rights reserved
---------------------- Page: 14 ----------------------
ISO 20078-3:2021(E)
REQ_05_01_34 To ensure the interoperability between involved entities in different physical envi-
ronments, an implementation shall follow a framework compatible with OAuth 2.0
and OpenID Connect 1.0.
Annex A provides one example of how to implement OAuth 2.0 and OpenID Connect 1.0.
5.2 Accessing party authorization domain
5.2.1 General
Subclause 5.2 describes the steps needed to make the offering party authorized to push resources to
the accessing party. Figure 8 shows an example of the order of these steps. Steps 1 and 2 are already
covered in 5.1 and are only included in Figure 8 to show a complete flow.
NOTE 1 In step 5, resource provider is using authorization information provided in step 2.
NOTE 2 In case the offering party is also the resource owner, step 2 is implicit.
a
Step 1: the resource owner is authenticated by the identity provider (see 5.1).
b
Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization
provider of the offering party (see 5.1).
c
Step 3: the accessing party grants access to the offering party to push resources.
d
Step 4: the accessing party initiates the subscription, either explicitly or through other means.
e
Step 5: the offering party pushes the resource to the accessing party.
Figure 8 — Overview of communication flows
5.2.2 Authorization
The resource provider as a component of the offering party requires access to push resources to the
client application of the accessing party.
11
© ISO 2021 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 20078-3:2021(E)
REQ_05_02_01 The accessing party shall authorize the offering party to push resources when there
is an active subscription.
REQ_05_02_02 The accessing party shall provide a bearer token and expiry time to the offering
party.
Or
The accessing party shall provide a refresh token and expiry time to the offering
party. The refresh token can be used to renew the access token.
Either one or both of these options shall be implemented by the offering party
when pushing resources.
5.2.3 Pushing resources
The offering party uses the bearer token to be authorized at the accessing party when pushing resources
(see Figure 9).
REQ_05_02_03 The accessing party shall verify the bearer token before accepting the pushed re-
source(s).
a
Request of a new access token is required if refresh token grant type is used in the subscription.
Figure 9 — Logical representation of push method
in reference to the defined requirements
Annex B provides reference implementation for push.
12
© ISO 2021 – All rights reserved
---------------------- Page: 16 ----------------------
ISO 20078-3:2021(E)
Annex A
(informative)
Reference implementation using OAuth 2.0 and OpenID Connect
1.0
A.1 Introduction
This reference implementation is designed in accordance with the general approach (see Clause 4)
[1] [2]
using OAuth 2.0 framework and OpenID Connect 1.0 specifications. OAuth 2.0 is used to implement
an authorization mechanism for requesting of authorization and accessing resources. OpenID Connect
1.0 is used as an authentication layer on top of the OAuth 2.0 framework for resource-owner related
scenarios, where the proof of the resource-owner identity using appropriate authentication method
through an identity provider is required (see Figure A.1).
Figure A.1 — Extended vehicle split to the usage of OAuth 2.0 and OpenID Connect 1.0
The client application of the accessing party should support an implementation of the standard OAuth
[1]
2.0 for authorization requests and access to protected resources, and may support OpenID Connect
[2]
1.0 for resource owner authentication and access to the profile of the resource owner.
Both standards are using the term "authorization server". However, this document differentiates
between logical components, the "identity server" maintained by the identity provider and the
"authorization server" maintained by the authorization provider. In this reference implementation,
the ExVe identity server refers to OpenID Connect 1.0 authorization server and the ExVe authorization
server refers to OAuth 2.0 authorization server.
The reference implementation does not cover all of the technical details. The terms and definitions to
facilitate the understanding of the referenced implementation are provided in Clause 3.
13
© ISO 2021 – All rights reserved
---------------------- Page: 17 ----------------------
ISO 20078-3:2021(E)
The implementation of the components should comply with the following guidelines.
[2]
— For resource owner authentication, OpenID Connect 1.0 Authorization Code Flow, OIDC Core
should be used by the accessing party.
[2]
— The identity provider should provide a “UserInfo” end point as defined in OpenID Connect 1.0 to
make the resource owner profile available.
— OAuth 2.0 grant type "authorization code" is recommended when requesting authorization for
[1]
protected resources owned by a resource owner, RFC 6749 . Offering party and accessing party
can agree on other grant types.
— In the authorization code flow, the client application will first get an authorization code which then
needs to be exchanged for the identity token (identity provider) or the access token (authorization
provider).
— The identity provider and/or the authorization provider may request a registration of the client
application before the client application can consume services provided by the identity server
and/or the authorization server. With successful registration the client application will receive
client credentials. The design of the client registration process, the credential type and the client
authentication method are under the responsibility of the identity provider and the authorization
provider.
— OAuth 2.0 grant type "client credentials" can be used for resources, where runtime interaction with
[1]
the resource owner is not required, RFC 6749 .
— The authorization server and the identity server should provide a service for revocation of granted
[7]
permissions in accordance with RFC 7009 .
— The issuer of tokens (identity server, authorization server) may expose OAuth 2.0 token introspection
[4]
end points according to RFC 7662 .
— All tokens (identity token, refresh token, access token) should be digitally signed using asymmetric
[8] [5]
keys as defined in RFC 7515 . Allowed algorithms are defined in RFC 7518 .
— The token issuer should provide all valid public keys for signature validation as defined in
[3]
RFC 7517 .
[9]
— The access token type should be bearer as defined in RFC 6750 .
— The access tokens may be self-contained or may reference the authorization information stored at
the token issuer. Self-contained access tokens allow the resource server to perform an authorization
decision without further interaction with the authorization server. To allow the reliable revocation
of self-contained tokens the lifetime should be limited to maximum one hour.
— If issued, the client application should store refresh tokens in a long-term secur
...
FINAL
INTERNATIONAL ISO/FDIS
DRAFT
STANDARD 20078-3
ISO/TC 22/SC 31
Road vehicles — Extended vehicle
Secretariat: DIN
(ExVe) web services —
Voting begins on:
2021-08-23
Part 3:
Voting terminates on:
Security
2021-10-18
Véhicules routiers — Web services du véhicule étendu (ExVe) —
Partie 3: Sécurité
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/FDIS 20078-3:2021(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO 2021
---------------------- Page: 1 ----------------------
ISO/FDIS 20078-3:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/FDIS 20078-3:2021(E)
Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 2
4.1 Processes . 2
4.2 Conditions . 2
5 Basic communication flow . 3
5.1 Offering party authorization domain . 3
5.1.1 General. 3
5.1.2 Authentication . 3
5.1.3 Authorization . 4
5.1.4 Resource access . 6
5.1.5 Separation of duties . 7
5.1.6 Implementation related considerations . 9
5.2 Accessing party authorization domain .11
5.2.1 General.11
5.2.2 Authorization .12
5.2.3 Pushing resources .12
Annex A (informative) Reference implementation using OAuth 2.0 and OpenID Connect 1.0 .14
Annex B (informative) Reference implementation for push .22
Bibliography .25
© ISO 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/FDIS 20078-3:2021(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 20078-3:2019), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— defined authorization domains for the offering party and the accessing party;
— added new requirements and description related to push method to make the offering party
authorized to push resources to the accessing party;
— added Annex B containing description of reference implementation for push.
A list of all parts in the ISO 20078 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 20078-3:2021(E)
Road vehicles — Extended vehicle (ExVe) web services —
Part 3:
Security
1 Scope
This document defines how to authenticate users and accessing parties on a web-services interface. It
also defines how a resource owner can delegate access to its resources to an accessing party. Within
this context, this document also defines the necessary roles and required separation of duties between
these in order to fulfil requirements stated on security, data privacy and data protection.
All conditions and dependencies of the roles are defined towards a reference implementation using
[1] [2]
OAuth 2.0 compatible framework and OpenID Connect 1.0 compatible framework.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 20078-1, Road vehicles — Extended vehicle (ExVe) web services — Content and definitions
3 Terms and definitions
For the purposes of this document, the convention, terms and definitions given in ISO 20078-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
identity token
ID token
digitally signed JWT and contains claims (3.3) about the authenticated resource owner
3.2
authorization code
intermediate result of a successful resource-owner authorization process and that is used by authorized
clients to obtain access tokens and optionally refresh tokens
3.3
claim
asserted information about a certain entity
EXAMPLE ROID, resource owner’s first name, last name, address, connected vehicle’s capability and/or
other attributes.
3.4
token issuer
entity that generates and provides identity tokens (3.1), access tokens, and refresh tokens
© ISO 2021 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO/FDIS 20078-3:2021(E)
3.5
authorization domain
domain of activity where an entity controls the authorization
Note 1 to entry: The offering party controls the authorization in the offering-party authorization domain and the
accessing party controls the authorization in the accessing-party authorization domain.
Note 2 to entry: Due to the description of push communication in 5.2 there exists two different authorization
providers. One at the side of the accessing party and one at the side of the offering party.
4 General
4.1 Processes
The following processes are specific to each offering party. The definition of these processes is not part
of this document but shall be in place in order to apply this specification.
REQ_04_01_01 The process to register a resource owner at the identity provider shall be the re-
sponsibility of the offering party.
REQ_04_01_02 The process to register an accessing party at the authorization provider shall be the
responsibility of the offering party.
REQ_04_01_03 The process to confirm the technical eligibility of connected vehicles and provision
of their associated ExVe resources shall be the responsibility of the offering party.
REQ_04_01_04 The process to verify a resource owner’s current and valid ownership of the con-
cerned resource shall be the responsibility of the offering party.
REQ_04_01_05 The process to register the offering party in the accessing party authorization domain
shall be the responsibility of the accessing party. This is only needed if resources
shall be pushed.
4.2 Conditions
REQ_04_02_05 The offering party shall be able to restrict or deny the accessing party and/or the
resource owner access to the offering party’s web services and portals.
NOTE 1 This can be done, for example, to fulfil security and legislation requirements.
REQ_04_02_06 If the offering party revokes a granted registration of an accessing party, the offering
party may delete all containers created by the accessing party, if containers are used.
NOTE 2 Revocation of the registration can be due to access violation or other misuse of the web services.
REQ_04_02_07 The accessing party shall be able to restrict or deny the offering party’s ability to
push resources.
NOTE 3 This can be done, for example, to fulfil security and legislation requirements.
2 © ISO 2021 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/FDIS 20078-3:2021(E)
5 Basic communication flow
5.1 Offering party authorization domain
5.1.1 General
This document separates the activities necessary for authentication, authorization and resource access
into three distinct communication flows with separate duties (see Figure 1).
a
Step 1: the resource owner is authenticated by the identity provider.
b
Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization
provider.
c
Step 3: the accessing party is accessing resources from the resource provider.
Figure 1 — The roles and the three distinct communication flows
5.1.2 Authentication
The identity provider is responsible for authenticating the resource owner and managing the resource
owner profile, based on the resource owner registration. The resource owner credentials are revealed
only to the identity provider, and the identity provider confirms a successful authentication to
concerned parties. If the resource owner has given consent, the accessing party will be authorized to
access the resource owner's profile (Figure 2).
© ISO 2021 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO/FDIS 20078-3:2021(E)
Figure 2 — Resource owner authentication and access to resource owner’s profile
REQ_05_01_01 The identity provider shall offer a suitable authentication method and shall perform
the authentication process. After a successful authentication, the identity provider
shall confirm the identity of the authenticated resource owner.
REQ_05_01_02 The resource owner’s credentials shall only need to be known by the resource owner
and be possible to be verified by the identity provider.
REQ_05_01_03 The resource owner’s registration and authentication (at the identity provider), shall
be separated from the authorization process to grant access to resources (via the
authorization provider).
REQ_05_01_04 If the identity provider is able to expose the resource owner’s profile to the accessing
party, it is only the resource owner that shall be able to grant or deny access.
5.1.3 Authorization
The client application as a component of the accessing party requires access to resources on behalf of
the resource owner. At the authorization step, the accessing party requests authorization to access the
resources provided by the resource provider (offering party). The required authorization is requested
at the authorization provider, providing the intended scope. By the consent of the resource owner, the
authorization provider returns a limited authorization to the client application of the accessing party.
Using the obtained authorization, the client application can access resources. authorization to access
resources is done in the same way regardless, if the resources are fetched by the accessing party using
request/reply or pushed by the offering party (see Figure 3). See ISO 20078-2 for details regarding
request/reply and push.
4 © ISO 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/FDIS 20078-3:2021(E)
Figure 3 — Requesting access to resources
REQ_05_01_05 Before accessing the resource, the accessing party shall request access at the au-
thorization provider providing the intended scope.
REQ_05_01_06 The authorization provider shall be responsible for the management of the author-
ization policy and shall manage all granted accesses.
NOTE 1 The authorization policy, for example, defines the permissions of the accessing party, primarily the
conditions to be met for granted access to resources.
REQ_05_01_07 The authorization provider shall trust the confirmation of successful authentication
as provided by the identity provider.
REQ_05_01_08 The authorization policy shall be defined by the offering party concerning the au-
thorization process.
REQ_05_01_09 The authorization provider shall be able to verify the relationship between resource
owners and their resources.
REQ_05_01_10 Only the resource owner shall be able to grant access to a resource.
NOTE 2 The access is granted to an accessing party at the offering party.
REQ_05_01_11 Granting access to resources shall be done either directly or via containers. The
offering party decides if one or both of the granting methods shall be provided to
the accessing parties.
© ISO 2021 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO/FDIS 20078-3:2021(E)
REQ_05_01_12 The resource owner shall be able to revoke a granted access to a resource at any time.
REQ_05_01_13 If containers are used, the resource owner shall be able to revoke a granted access
to a containers at any time.
REQ_05_01_14 The authorization provider shall ask the resource owner for the approval before
providing the authorization to the accessing party resulting in a granted access.
REQ_05_01_15 Upon request the offering party shall present a resource owner’s granted accesses
to the resource owner.
REQ_05_01_16 The resource owner shall be able to deny an access request to a resource, or if con-
tainers are used, to a container at any time.
REQ_05_01_17 If the ownership of a resource or the relationship between the resource owner and
the resource ends, access to the corresponding resources, and if containers are used,
also to containers, shall be revoked.
REQ_05_01_18 If containers are used and if a container is deleted, all access granted to that con-
tainer shall be revoked.
5.1.4 Resource access
Using the access, the accessing party can access the resources, hosted by the resource provider (see
Figure 4).
Figure 4 — Access to resources via the resource provider
REQ_05_01_19 The resource provider shall perform access control to the resources according to
the authorization policy.
6 © ISO 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/FDIS 20078-3:2021(E)
5.1.5 Separation of duties
Separation of duties concerns the separation of tasks and responsibilities between entities involved in
the authentication, authorization and access to resources.
Figure 5 — Separation of duties between involved roles
Figure 5 describes the separation of duties between involved roles, where the offering party has the
three roles: identity provider, authorization provider, and resource provider.
REQ_05_01_20 The identity provider shall not be dependent on the authorization policy.
REQ_05_01_21 The identity provider shall not influence the authorization policy.
REQ_05_01_22 The identity provider shall not access the resources.
REQ_05_01_23 The authorization provider shall not access the resource owner profile.
© ISO 2021 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO/FDIS 20078-3:2021(E)
REQ_05_01_24 The authorization provider shall only use the unique ResourceOwnerID to identify
the resource owner.
NOTE 1 The ResourceOwnerID is generated and communicated by the trusted identity provider.
REQ_05_01_25 The authorization provider shall not have access to resources provided by the re-
source provider.
REQ_05_01_26 The resource provider shall not access the resource owner profile.
REQ_05_01_27 The resource provider shall not know details about the authorization process.
REQ_05_01_28 The resource provider trusts the authorization provider and shall verify whether the
provided authorization matches the access control rules defined for the requested
resources.
REQ_05_01_29 The resource owner shall not need to share credentials with the accessing party to
enable the accessing party to access the resources.
REQ_05_01_30 The accessing party shall only access the resources with the consent of the resource
owner.
NOTE 2 The requirements stated above do not impose requirements on specific architecture, design or
organizational structure.
Figure 6 shows the major logical components of the involved roles and the associated entities.
8 © ISO 2021 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/FDIS 20078-3:2021(E)
Figure 6 — Involved roles and associated entities
5.1.6 Implementation related considerations
The physical implementation and assignment of roles to real parties differs from the logical
representation as shown in Figure 6, and follows the defined requirements as referenced by Figure 7.
© ISO 2021 – All rights reserved 9
---------------------- Page: 13 ----------------------
ISO/FDIS 20078-3:2021(E)
Figure 7 — Logical representation of involved roles and their entities
in reference to the defined requirements
Additionally, actual implementation often depends on national legal requirements (e.g. handling of
resource owner profile, implemented resource owner’s verification process etc.) and the required
trusted relationship between involved components especially identity provider, authorization provider,
and resource provider.
REQ_05_01_31 All communication paths between involved entities shall use secured connections.
REQ_05_01_32 The identity provider, authorization provider, and resource provider are responsible
for ensuring that only recent cipher suites are used.
NOTE 1 Changes in the interface are communicated to accessing parties within a reasonable notice period.
If the offering party encounters an unreliable accessing party, the offering party can temporarily or
permanently revoke the accessing party’s access. This is done in order to protect the resource owners.
Examples of circumstances that could trigger this are: insecure smartphone applications, disabled
host verification, data breach of database, forbidden caching or storage of resource data, usage of
discouraged security algorithms.
REQ_05_01_33 It shall be possible to validate the authenticity and integrity of information provided
by the identity provider, authorization provider and resource provider.
10 © ISO 2021 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/FDIS 20078-3:2021(E)
REQ_05_01_34 To ensure the interoperability between involved entities in different physical envi-
ronments, an implementation shall follow a framework compatible with OAuth 2.0
and OpenID Connect 1.0.
Annex A provides one example of how to implement OAuth 2.0 and OpenID Connect 1.0.
5.2 Accessing party authorization domain
5.2.1 General
Subclause 5.2 describes the steps needed to make the offering party authorized to push resources to
the accessing party. Figure 8 shows an example of the order of these steps. Steps 1 and 2 are already
covered in 5.1 and are only included in Figure 8 to show a complete flow.
NOTE 1 In step 5, resource provider is using authorization information provided in step 2.
NOTE 2 In case the offering party is also the resource owner, step 2 is implicit.
a
Step 1: the resource owner is authenticated by the identity provider (see 5.1).
b
Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization
provider of the offering party (see 5.1).
c
Step 3: the accessing party grants access to the offering party to push resources.
d
Step 4: the accessing party initiates the subscription, either explicitly or through other means.
e
Step 5: the offering party pushes the resource to the accessing party.
Figure 8 — Overview of communication flows
© ISO 2021 – All rights reserved 11
---------------------- Page: 15 ----------------------
ISO/FDIS 20078-3:2021(E)
5.2.2 Authorization
The resource provider as a component of the offering party requires access to push resources to the
client application of the accessing party.
REQ_05_02_01 The accessing party shall authorize the offering party to push resources when there
is an active subscription.
REQ_05_02_02 The accessing party shall provide a bearer token and expiry time to the offering
party.
Or
The accessing party shall provide a refresh token and expiry time to the offering
party. The refresh token can be used to renew the access token.
Either one or both of these options shall be implemented by the offering party
when pushing resources.
5.2.3 Pushing resources
The offering party uses the bearer token to be authorized at the accessing party when pushing resources
(see Figure 9).
REQ_05_02_03 The accessing party shall verify the bearer token before accepting the pushed re-
source(s).
a
Request of a new access token is required if refresh token grant type is used in the subscription.
Figure 9 — Logical representation of push method
in reference to the defined requirements
12 © ISO 2021 – All rights reserved
---------------------- Page: 16 ----------------------
ISO/FDIS 20078-3:2021(E)
Annex B provides reference implementation for push.
© ISO 2021 – All rights reserved 13
---------------------- Page: 17 ----------------------
ISO/FDIS 20078-3:2021(E)
Annex A
(informative)
Reference implementation using OAuth 2.0 and OpenID Connect
1.0
A.1 Introduction
This reference implementation is designed in accordance with the general approach (see Clause 4)
[1] [2]
using OAuth 2.0 framework and OpenID Connect 1.0 specifications. OAuth 2.0 is used to implement
an authorization mechanism for requesting of authorization and accessing resources. OpenID Connect
1.0 is used as an authentication layer on top of the OAuth 2.0 framework for resource-owner related
scenarios, where the proof of the resource-owner identity using appropriate authentication method
through an identity provider is required (see Figure A.1).
Figure A.1 — Extended vehicle split to the usage of OAuth 2.0 and OpenID Connect 1.0
The client application of the accessing party should support an implementation of the standard OAuth
[1]
2.0 for authorization requests and access to protected resources, and may support OpenID Connect
[2]
1.0 for resource owner authentication and access to the profile of the resource owner.
Both standards are using the term "authorization server". However, this document differentiates
between logical components, the "identity server" maintained by the identity provider and the
"authorization server" maintained by the authorization provider. In this reference implementation,
the ExVe identity server refers to OpenID Connect 1.0 authorization server and the ExVe authorization
server refers to OAuth 2.0 authorization server.
The reference implementation does not cover all of the technical details. The terms and definitions to
facilitate the understanding of the referenced implementation are provided in Clause 3.
14 © ISO 2021 – All rights reserved
---------------------- Page: 18 ----------------------
ISO/FDIS 20078-3:2021(E)
The implementation of the components should comply with the following guidelines.
[2]
— For resource owner authentication, OpenID Connect 1.0 Authorization Code Flow, OIDC Core
should be used by the accessing party.
[2]
— The identity provider should provide a “UserInfo” end point as defined in OpenID Connect 1.0 to
make the resource owner profile available.
— OAuth 2.0 grant type "authorization code" is recommended when requesting authorization for
[1]
protected resources owned by a resource owner, RFC 6749 . Offering party and accessing party
can agree on other grant types.
— In the authorization code flow, the client application will first get an authorization code which then
needs to be exchanged for the identity token (identity provider) or the access token (authorization
provider).
— The identity provider and/or the authorization provider may request a registration of the client
application before the client application can consume services provided by the identity server
and/or the authorization server. With successful registration the client application will receive
client credentials. The design of the client registration process, the credential type and the client
authentication method are under the responsibility of the identity provider and the authorization
provider.
— OAuth 2.0 grant type "client credentials" can be used for resources, where runtime interaction with
[1]
the resource owner is not required, RFC 6749 .
— The authorization server and the identity server should provide a service for revocation of granted
[7]
permissions in accordance with RFC 7009 .
— The issuer of tokens (identity server, authorization server) may expose OAuth 2.0 token introspection
[4]
end points accordi
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.