BS ISO 20078-3:2021 pdf free download – Road vehicles一Extended vehicle (ExVe) web services Part 3: Security.
A.2.2 ID token claims
In addition to required claims defined in OpeniD Connect 1.0121, an ID token can contain the following custom claim:
exve.roid (Unique ResourceOwneriD)
A.2.3 Access token claims
In addition to required claims defined in RFC 7519LHi, an access token may contain the following custom claims:
exve.roid (ResourceOwnerlD)
exve.cid (ContaineriD)
exve.rid (ResourcelD)
One or more access IDs are linked to the ResourceOwnerlD, ResourcelDs and/or ContaineriDs.
A.2.4 Refresh token claims
In addition to required claims defined in RFC 7519[U1, a refresh token should at a minimum contain the following custom claim:
exve.roid (Unique ResourceOwneriD)
NOTE The refresh token is used with the scope to request a new access token, as the refresh token only contains the ResourceOwneriD.
A.3 Use cases
A.3.1 Access to protected resources with resource owner’s approval at runtime The accessing party wants to access resource owner-related resources and an authorization at runtime
is required (approval).
This initial access needs four steps:
1) resource owner authentication (and optionally granting access to the resource owner’s profile) by the identity provider;
2) obtain basic profile information about the resource owner from the identity provider;
3) requesting authorization for required resources at the authorization provider;
4) access to resources at the resource provider.
In the following example the accessing party has implemented an application running on a web server (client application) and interacting with the resource owner via a user agent (browser).
NOTE Different colours in Figure A.2 are used to facilitate understanding of the diagram, they do not have any technical meaning.
The browser hands over the authorization code to the client application server. With the authorization code the client application server requests a digitally signed ID token from the identity provider. If optionally requested and granted, the client application can get additionally the access token for the “Userlnfo” end point, issued by the identity server for the scope granted by the resource owner. The issued tokens are typically only valid for the requesting client, i.e. in this example the client application.
2) The client application can use the access token for the “Userinfo” end point to obtain (as an example) the basic profile of the resource owner. The basic profile contains, for example, a subset of the resource owner’s profile data. This step is optional; the ID token itself can hold enough personal information for some use cases. The needed identity scope (subset) can vary depending on the use case and is granted by the resource owner (ci. step 1).
3) A request for authorization is based on the authorization code grant as defined in RFC 6749111. Depending on the availability and validity of the refresh token, the client application can request the authorization following either step 3 a) (first-time access) or step 3 h) (subsequent authorization requests if refresh token is available and valid).
1) The client application and the authorization server are establishing a secure HTTP connection (HTTPS) by using mutual TLS authentication. The client application requests an access token for the required resources, providing the intended scope. The authorization server validates the client identity, the requested scope and the availability of corresponding resource owner’s consent. After a successful validation, the authorization server issues and returns the digitally signed access token to the client application.