Multiple scopes within access token

[aw-muc]

Currently access tokens issued with JWT pattern mentioned in the core document (see, https://www.w3.org/TR/viss2-core/#access-token), allows only one purpose within the "scp"-field.
If an application needs to grant rights for multiple scopes to access data of different scopes, the application needs to handle multiple tokens based on the different scopes. Even the number of requests would increase, because for every token/scope pair a single request needs to be done against the VISS-server instead handling a request baes on a JWT token with multiple purpose-scopes that requests only the required data.

[UlfBj]

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.

[tguild]

Minutes from that call

[aw-muc]

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.

[UlfBj]

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.

[aw-muc]

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?

[isaacagudo]

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 ...

[UlfBj]

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.

[isaacagudo]

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