Hi,
Is there a better way of reviewing changes in the html files than just using GitHub ? I feel it is very tedious … I guess you need to clone the fork and the open the files but with a diff tool that renders html ?
The system user identity corresponds to the identity of the user currently active inside the vehicle. It is assumed that this identity belongs to the user currently in charge of operating the vehicle (i.e., the driver). The system will usually have credentials to act as this user with respect to other backend systems (e.g., to access personalized navigation functionality). The system user identity shall be available to the auth server from the environment (i.e., the platform the auth server is running on, e.g., the main unit).
+
In the future, there may be situations where more than one user identity is considered active on the system (i.e., the vehicle is personalized for multiple users, including potential passengers). In this case, additional metadata about the system users (e.g., which screen belongs to their seat) may be required for making authorization decisions. This use case, however, is not covered by the current version of this specification.
+
The client/system user Id descriptions above should be extended with a cloud based client.
+
Scopes
+
When requesting access to services, the client must specify a scope it wants to get access to. A scope describes a logical set of services. This facilitates the specification of policies as well as describing the current state of authorization to users, if need be. Clients request access to a certain scope and a service expects an access token for a certain scope. Similarly, the authorization server is not concerned with particular services but just with more abstract scopes. Using scopes allows the reuse of an access token for multiple services, which reduces the burden on client-side token management as well as requests against the auth server. Additionally, scopes also allow more fine-grained access control, where one service might expect different scopes for operations of different sensitivity (e.g., read vs. write).
+
There shall be two types of scopes: internal scopes are granted based on client properties (e.g. client identity or client type) without user interaction; conversely, user scopes may be granted through user interaction, i.e. a popup asking the user to decide whether or not a certain client should be able to use certain functionality. These user-scopes shall be defined in a way that facilitates understanding of a grant decision when being presented to a user, i.e., so that the set of services grouped into the scope carries meaning to a user. Otherwise, users are not able to effectively exercise the control that is expected by the system to protect them from unwanted accesses.
+
Every client has to know which scopes to request access á priori, i.e. the scope usually are to be known at implementation time.
+
User Scopes
+
As a reference, the following set of scopes shall be used to govern access:
+
+
+
+
Scope Label
+
Description
+
How do the scopes relate to the Taxonomy? Should it be mentioned here or come straight from the taxonomy (e.g. on 1st branch level or similar?
I would like to propose, if the group accepts, that rebase (the option named rebase-and-merge in GitHub) is preferred over the merge option. Otherwise we end up in situations like the above, where the pull request itself has some local merges (how?), and basically 3 of the PR commits are merges themselves. This PR really only has 3 commits that propose new content, and 3 "useless" merge commits. It is messy and IMHO the commit content matters, but the PR references you get from a merge commit are only useful to keep while reviewing, and then immediately obsolete.
Hi, Is there a better way of reviewing changes in the html files than just using GitHub ? I feel it is very tedious … I guess you need to clone the fork and the open the files but with a diff tool that renders html ?