Skip to content
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

Identifying VO membership from the issuer #29

Open
paulmillar opened this issue Aug 2, 2023 · 3 comments
Open

Identifying VO membership from the issuer #29

paulmillar opened this issue Aug 2, 2023 · 3 comments

Comments

@paulmillar
Copy link
Contributor

paulmillar commented Aug 2, 2023

Although not explicit stated (see #28), an issuer will only issue tokens to a single VO.

Therefore, it seems logical (at least, to me) that a service might be able to deduce the VO membership of the the agent (person or software) bearing the token, using only information from the iss claim. This would be true even if the token contains no information on group membership: the service may still identify the corresponding VO even if the wlcg.groups claim is either missing or empty.

In that sense, the iss claim identifies the VO.

If this approach seems reasonable, the document should be updated to make it clear that a service MAY (RFC 2119) identify the VO from the issuer (iss) claim.

If this approach is not reasonable, then the document should be updated to make it clear that a service MUST NOT (RFC 2119) identify the VO from the issuer (iss) claim.

Note This issue is very specifically only about identifying the VO. If identifying the VO from the iss claim is acceptable, this issue deliberately makes no comment on how the service might use that VO-membership information.

@DrDaveD
Copy link
Contributor

DrDaveD commented Aug 2, 2023

Again, it depends on exactly what you mean by "VO".

@paulmillar
Copy link
Contributor Author

paulmillar commented Aug 3, 2023

See #38 for a separate issue regarding the document's lack of definition of a "VO".

In any case, I think this issue cannot be resolved before #28 is first resolved.

@maarten-litmaath
Copy link
Collaborator

Please check #47 that tries to address the aforementioned concerns to some extent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants