Multiple scopes within access token about automotive HOT 8 CLOSED

This was discussed in the WG yesterday. The view was that the additional protocol flow under developed on issue 382, where the signal scope in an access token is not limited to the scope sets available in the purpose list policy document, should provide sufficient flexibility.

from automotive.

Minutes from that call

from automotive.

Okay, after having a look at the issue the alternative with the additional claim "sac" instead of "scp" and "clx" would work for my desired use cases. After reading the comment from @isaacagudo there is still a question about the access grant token. How can the server analyze if the requested sac claims are compatible with the grant access token to create the required access token with the sac claims, because the access grant token does not have any information about scopes, purposes or sac's if i look at the definition here.

from automotive.

The access grant token is out of scope for Open flow alternative in the PR432.
The sac claim is validated against the signals in the request.

from automotive.

Just to understand that correctly, to run with the sac-claim, I can should only run with short term access tokens. So based on that the client needs to handle two different auth-flows (long term with grant access token and scp claims, and shot term with only access tokens based on sac claims)?
At the moment the standard within Access Token Server and Access token request, defines "Purpose" as a requirement. In future, if the sac claim would be part of the standard, a sac list can also be added instead of a purpose correct?

from automotive.

sac claims should work both with short and long term access grant token. The scp claim points to purpose short name, which points to a list of signals. An alternative would be to accept as scp either a short name or a list of signals ...

from automotive.

The Open flow as described in this version of the spec (the PR pointed to a version not including it, updated now)
https://rawcdn.githack.com/UlfBj/automotive/7065a2f43aca2035e2a9bd763f33d44a7718c4ad/spec/VISSv2_Core.html
does not mandate use of either the Access Grant Token Server, or the Access Token Server, only the format of the Access Token for the Open flow is mandated.
So even if this new Access Token format could be used together with these servers, it is not mandatory.
I hope reading chapters 8.2 and 8.5.3 on the link above clarifies this.

from automotive.

This is already taken care in two alternative PR: #435 and #432

from automotive.