-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple scopes within access token #422
Comments
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. |
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. |
The access grant token is out of scope for Open flow alternative in the PR432. |
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)? |
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 ... |
The Open flow as described in this version of the spec (the PR pointed to a version not including it, updated now) |
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.
The text was updated successfully, but these errors were encountered: