BS ISO 20078-3:2019 pdf free download – Road vehicles – Extended vehicle (ExVe) web services.
The implementation of the components should comply with the following guidelines.
— For Resource Owner authentication, OpeniD Connect 1.0 Authorization Code Flow, OIDC Core should be used by the Accessing Party.
— The Identity Provider should provide a “Userinfo” endpoint as defined in Open ID Connect 1.0121 to make the Resource Owner Profile available.
— OAuth 2.0 grant type Authorization Code is recommended when requesting authorization for protected Resources owned by a Resource Owner, RFC 6749111. 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 the Resource Owner is not required, RFC 6749111.
— The Authorization Server and the Identity Server should provide a service for revocation of granted permissions in accordance with the OAuth 2.0 Token Revocation, RFC 7009121.
— The Issuer of tokens (Identity Server, Authorization Server) may expose OAuth 2.0 Token Introspection Endpoints according to RFC 7662141.
— All tokens (identity token, refresh token, access token) should be digitally signed using asymmetric keys as defined in JSON Web Signature (1WS), RFC 7515.1I1 Allowed algorithms are defined in JSON Web Algorithms, RFC 7518151.
— The Token Issuer should provide all valid public keys for signature validation as defined in JSON Web Key (JWK), RFC 7517111.
— The Access token type should he bearer as defined in RFC 6750191.
— 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 secure storage and continue to use them as long as they remain valid. Refresh tokens should be treated by the clients as a secret and need only be sent exclusively to the issuer of the refresh token.