Question about Authorize() detail

[aShinjiroUrata]

Hi,
Currently, I'm thinking about how to implement authorize() method and have some questsions.
One of the questions is below.

When authorize() is executed with a token( user token and/or device token ), I suppose VISS server will validate the token.
At this point,
a) VISS server always grant the access to the request with valide token?
Or,
b) VISS server may reject the access request even if the token is valid?

If a) is the case, token's validity is only important thing and if token is valid,
the user will be able to access any data point.
This is very simple but I suppose this is not Kevin-san's intention.

If b) is the case, VISS server should have some database in which token's access right is defined such as "tokenA can access VehicleSpeed, engine RPM", "tokenB can access door lock status", etc.
If every users have different token, VISS server has to have a large database for this purpose and I feel not efficient nor realistic way.

I think this is implementation detail matter and I don't think this kind of detail should be written in the spec.
I'd like to know if Kevin-san and Adam-san's have original idea about this point.

[rstreif]

@aShinjiroUrata,

While we purposely have not defined how a token should look like because we wanted to give implementers the freedom on how the want to implement security, we have made a suggestion as to what the token should contain:

Path: The signal path (defined here) the token authorizes. The path may be a branch name or contain wildcards to authorize entire branches.
Actions: List of actions that the token authorizes for the path. The list contains at least one of the actions getVSS, get, set, subscribe and unsubscribe.
Valid From: Timestamp in UTC indicating the date and time from which on the token is valid.
Valid Until: Tmestamp in UTC indicating the date and time until which the token is valid.

So, if either the path and/or actions are missing then the server should reject the token as being invalid. I think the VISS should not be required to remember any tokens. But of course, you are free to implement it as you see best fit and security for your application.

[aShinjiroUrata]

Hi @rstreif

Thanks for the suggestion!

While we purposely have not defined ....

I understand and this is OK to me.

Path, Actions, Valid From, Valid Until ...

In my understanding, these are kind of additional information and there should be token core part such as OAuth2.0 or something.
So a token may be look like

Token = {
  path: “Signal.Drivetrain.Transmission.Speed”,
  actions: [‘get’, ‘subscribe’, ‘unsubscribe’],
  valid_from: ‘2017/02/28-12:00:00.000’,
  valid_to   : ‘2018/02/28-12:00:00.000’,
  token_core: <'OAuth2.0 access token', 'JWT', etc.>
}

Existence check of 'path, actions, valid_from, valid_to' is just a data format validation
and I think more important validation is about legitimacy of the token (and token's owner).
I think this validation is depend on token_core part.

In case of OAuth2.0, I can get OAuth2.0's access token from service provider such as Twitter via OAuth2.0 sequence.
If I am a valid user of Twitter, I can get 'access token' and If I execute authorize() with this access token, VIS server should recognize I am valid user.

My question was, when user_A have valid token, VIS server should always accept authorize() request or in some case, VIS server can refuse the request.

If VIS server always accept the request, then executing authorize() by specifying path is, I feel, not very meaningful since if user_A has valid token, he can do everything and so executing authorize() only once is enough.

In latter case, VIS server should know user_A's accessibility information such as
user_A has right to execute:

- vehicelSpeed: get, subscribe
- HVAC: get, subscribe, set
- Door.isLocked: get, subscribe
- etc.

Having such database for all users inside VIS server is not practical and I don't want to do this.
In such case, I may want to classify users( and tokens) like guest_driver, owner_driver, passenger, maintainance_engineer etc and have accessibility table for those user classes.

Anyway, I understand these thing are implementer's freedom and I can decide as I like.
My objective is to create prototype which behave as described in VIS specification that can path test.
For this purpose I may not have to use real OAuth2.0 service but I may be able to use mock token and mock token validator. I'll work out by myself.

If there is no more comment, I close this issue.
Thanks!

[rstreif]

@aShinjiroUrata, now I understand better what you mean. My thinking here is not that the VISS authorization token embeds a core authorization token (token_core) such as OAuth2, JWT, etc. In this case it would be difficult avoid stripping the VISS authorizations from the core token (unless you add signature and/or encryption). My thinking is that the VISS authorization token is essentially an OAuth2, JWT, etc. token that in addition to its typical fields would also include the VISS-specific fields.

[aShinjiroUrata]

Hi Rudi-san,
Thanks for the comment.

In this case it would be difficult avoid stripping the VISS authorizations from the core token

I understand you mean, it would be difficult to protect core token from stripping for security purpose.

My thinking is that the VISS authorization token is essentially an OAuth2, JWT, etc. token that in addition to its typical fields would also include the VISS-specific fields.

I understand this is more secure.
According to your idea, to execute authorize() of
a) doorLock: get
b) doorLock: get, set, subscribe
I will need different authorization token, correct?

If so, in OAuth2.0 case, in my understanding OAuth2.0's access token is something provided by service provider such as Twitter.
Then I have to get different access token issued by some service provider for every authorize() execution and this might be bit too troublesome.
(I feel, OAuth2.0 might not be a good example for this story.)

Anyway, detail of security token is implementor's freedom and it is OK.
But I hope I'd like to have one known method with which, authorize() system could be realized with a popular token technology which may be example or guideline.

[rstreif]

Urata-san,

According to your idea, to execute authorize() of
a) doorLock: get
b) doorLock: get, set, subscribe
I will need different authorization token, correct?

Yes, a) would only allow you to read the door lock status and that can be done per door or by wildcarding the tree according to VSS. b) would also allow to lock and unlock the door and subscribe to the door lock status.

If so, in OAuth2.0 case, in my understanding OAuth2.0's access token is something provided by
service provider such as Twitter.
Then I have to get different access token issued by some service provider for every authorize()
execution and this might be bit too troublesome.
(I feel, OAuth2.0 might not be a good example for this story.)

Yes, I have to admit that I do not know much about OAuth2 tokens. They may not even work for our application. We would want to support tokens that can authorize different things with the same token.

For RVI we are using JWT, which are very suitable for this application.

[aShinjiroUrata]

Hi Rudi-san,

For RVI we are using JWT, which are very suitable for this application.
Thanks for the advise!
Then I'll consider with JWT.
But firsrtly , I'll go on with mock token and mock authorize system.

If there's no more comments, I'll close this issue.

[drkevg]

Hi,
I can outline my understanding of some of the thinking in the hope that it is helpful. But it is good to discuss to what extent the specification should define Authentication and Access Control.

My personal preference would be to keep the specification simple in this area and just use tokens to identity entities (user, vehicle devices, apps etc)

The idea was that 'out of band' a Security Authority would issue the token e.g. for the user (after user had authenticated using some credentials) or for the vehicle device (e.g. based on vehicle/device proving knowledge of a private key) . So tokens just validate the identity of entities.

The user and/or vehicle device tokens would be passed to the WebSocket server via the Authorize (which might more properly be called 'Authenticate' method) and on receipt of the token, the server verifies that the tokens are valid by checking with the Security Authority that issued it.

The Server implementation is then free to grant or deny access to data (i.e. manage access control) as it sees fit.

It could be that behind the scenes and outside of the scope of the specification, it may be that the server implements a set of roles for users and access to data is dependent on whether the user is a member of a particular role. For example, if the user associated with the token is a member of the 'OEMTester' role they are allowed to get/set/subscribe to ANY data, in order to support to support Quality Assurance testing. My personal view is the spec should not try to define roles and precise access control rules, just provide a mechanism to identify entities using tokens.

Personally, I wasn't expecting that the Security Authority would be Twitter but the OEMs Security Authority in the Cloud or in the vehicle (for system to work when no connectivity). Though to be explicit, I'm not saying that an OEM's implementation should not be allowed to accept a twitter OAuth token if that is how they have implemented their access control model. So they should be allowed to do this if they want or to accept e.g. Facebook or Google access tokens. More often though, I would expect the token to represent the user identity for the OEM and the OEM to have linked that user account with the user's Twitter, Spotify etc accounts.

The approach is quite general in that it allows any sort of security token that a Security Authority can grant (that can be passed via a JSON Authorize action fragment).

Our preference would be to keep access control separate from authentication and to just use the tokens to identify entities, and leave the implementer to be free to decide how to control access given they know the identity of the user and/or device (and or e.g. App) making the request.

It is good to discuss and keen that we get a good level of agreement on how we believe authentication and access control should be handled.

[aShinjiroUrata]

Hi Kevin-san,

Thank you very much for sharing the idea!

My personal preference would be to keep the specification simple in this area
and just use tokens to identity entities (user, vehicle devices, apps etc)

I understand that using tokens for user/device/app identity only or using
for access control as well could be a point of discussion.

My personal view is the spec should not try to define roles and precise access control rules,
just provide a mechanism to identify entities using tokens.

I agree. The spec should be kept simple and the role discussion should be implementer's freedom.

Personally, I wasn't expecting that the Security Authority would be Twitter
but the OEMs Security Authority in the Cloud or in the vehicle (for system to work when no connectivity).

I understand. I was just trying to find a quick way to use OAuth with prototype implementation.
Authentication with OEMs' Security Authority make sense to me.

Our preference would be to keep access control separate from authentication
and to just use the tokens to identify entities,

I like this idea since it is simple and easier to implement.

Thanks.

[rstreif]

AR: Reword the paragraph "While this specification does not mandate the token format and structure it shall at least contain the following elements to provide meaningful authorization:" to "While this specification does not mandate the token format and structure it is recommended that tokens least contain the following elements to provide meaningful authorization:"

[acrofts84]

As discussed, we will keep the VISS simple in this respect, and open to implementations. #192 simplifies the authorise section.