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

Status
Published
Publication Date
29-Nov-2021
Current Stage
6060 - International Standard published
Start Date
30-Nov-2021
Completion Date
30-Nov-2021
Ref Project

RELATIONS

Buy Standard

Standard
ISO 20078-3:2021 - Road vehicles -- Extended vehicle (ExVe) web services
English language
24 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/FDIS 20078-3:Version 21-avg-2021 - Road vehicles -- Extended vehicle (ExVe) web services
English language
25 pages
sale 15% off
Preview
sale 15% off
Preview

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
© 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.
© 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

© 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.

© 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).
Step 1: the resource owner is authenticated by the identity provider.

Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization

provider.
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
---------------------- 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.
© 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.
© 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.
© 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.
© 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.

© 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.

© 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.
© 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.

Step 1: the resource owner is authenticated by the identity provider (see 5.1).

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).

Step 3: the accessing party grants access to the offering party to push resources.

Step 4: the accessing party initiates the subscription, either explicitly or through other means.

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.
© 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.

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).

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.
© 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.

© 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).
Step 1: the resource owner is authenticated by the identity provider.

Step 2: the resource owner is granting access to the accessing party. The granting is handled by the authorization

provider.
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.

Step 1: the resource owner is authenticated by the identity provider (see 5.1).

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).

Step 3: the accessing party grants access to the offering party to push resources.

Step 4: the accessing party initiates the subscription, either explicitly or through other means.

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.

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).

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.