Group Membership Service: Request for Comments

Public discussion page for the IVOA GMS 1.0 Proposed Recommendation.

The original PR for the GMS Specification can be found at:

• PR-GMS-1.0-20210609

The updated draft GMS Specification (with some RFC points addressed) can be found on the github CI build:

• GMS-draft.pdf

Reference Implementations

• IA2 group at INAF developed a GMS implementation based on OAuth2 access tokens (JWT). The implementation is currently used by several astronomical portals for authorizing resource access. In addition to the standard search API some additional endpoints and a UI have been developed. The service is written in Java and source code is available at https://www.ict.inaf.it/gitlab/ia2/ia2-gms
• The CADC has been operating a GMS service since 2013. It is a critical component in the architecture as all authorization decisions are based on group membership. It is implemented with an LDAP back-end. The service has extended the GMS API to include mechanisms to allow users to create and manage their own groups and memberships.
  - Service and API: https://ws-cadc.canfar.net/ac
  - Source: https://github.com/opencadc/ac

• registered the CADC GMS service at 2021-10-29T18:00:00 with the very imaginative resource identifier ivo://cadc.nrc.ca/gms -- PatrickDowler - 2021-10-29
• registered the IA2 GMS service, IVOID set to ivo://ia2.inaf.it/gms. Available in full registries as of today, 2021-11-12 -- MarcoMolinaro

Comments from IVOA community members

Markus Demleitner

(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below".

Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"

• Thanks, I've changed the paragraph to be as you suggest. -- BrianMajor - 2021-10-25

(2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:

\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}

• Done. -- BrianMajor - 2021-10-25

(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect.

• Good suggestion. Done (but used http://rofr.ivoa.net/). -- BrianMajor - 2021-10-25

(4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere.

• A very good point and something that seems to be coming up frequently. Where to point tools that need to do registry lookups on a transactional basis? Anyhow, I've added a short paragraph at the end of section on resolving group identifers: "Clients and services that will require frequent lookups of GMS services should strongly consider caching a map of group identifiers keys to access URLs values. Access URLs probably change very infrequently. Caching would reduce the traffic on the RegTap services and improve the performance of authorization checks in general." -- BrianMajor - 2021-10-25

(5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later.

• Working on that, correspondence has been in github. -- BrianMajor - 2021-10-25
• As Pat mentions above, this is done for the CADC GMS service. I'm looking into whether the INAF service has been registered. The CADC resource ID is: ivo://cadc.nrc.ca/gms -- BrianMajor - 2021-11-02

(6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors?

• Hmm, intersting but I can't think of a use for an anonymous group. If the concept were to exist, it would probably be on the client side as it has intimate knowledge of the authorization decision being made. -- BrianMajor - 2021-10-25

-- MarkusDemleitner - 2021-09-13

Carlo Zwölf

(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome

• Thanks, I like this idea and anticipate other will ask the same. -- BrianMajor - 2021-10-25 I've created an issue for it here: https://github.com/ivoa-std/GMS/issues/8

(2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level.

• The next sentence "Users' identity is determined by one of the authentication mechanisms described in the IVOA Single-Sign-On Profile." is the attempt to defer the details of authentication to the VO SSO specification, as I thought it important not to include the same information in two places. Given this do you have a suggestion on how to improve the clairty? -- BrianMajor - 2021-10-25

(3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers?

• A group is not scoped beyond an instance of a GMS service. So, group1 in GMS-A is not the same group as group1 in GMS-B. The 'authority' part of the GMS ID is included, and the two services will have different authorities. -- BrianMajor - 2021-10-25

-- CarloMariaZwoelf - 2021-09-14

Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30

TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )

The Group Membership Service specifications fills the gap in interoperating authoritative services in the AuthN&AuthZ scenario of the IVOA Recommendations. It works on top of the group concept that collect autorization rights for singles or teams of users. GMS provides a simple API specification to cover the authorization checks when trying to access resources. The document has been fully reviewed by TCG.

Approved -- JanetEvans, MarcoMolinaro - 2022-02-17

Applications Working Group

The document looks good over all. Here are some aspects that we feel could strenghten it.

• I've added a bit of text around the caching of registry lookups as suggested by Markus. This is related so perhaps a dedicated paragraph is required. I'll rework this but at this time it is still TBD. -- BrianMajor - 2021-11-02
• I've created a github issue for this: https://github.com/ivoa-std/GMS/issues/13

-- AdrianDamian - 2021-10-29

Data Access Layer Working Group

The spec is well written and conveys the requirements clearly. We have two minor edits:

1. On p10, the citation for RFC 7234 is unknown.
2. sec.3.1, p.11: typo (right parenthesis without a left one): "[...] must end with a newline as a CRLF 1**)**."

-- JamesDempsey - 2021-12-20

-- GregoryMantelet - 2021-12-20

Thanks James and Gregory. I have fixed the parenthesis typo and am working on updating the bibliography in github so that the citation resolves.

-- BrianMajor - 2022-01-07

Data Model Working Group

Although this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.

• Section 1 : The standard is named Group Membership Service but there is no mention what groups are in section 1. This section could relate to individuals as well. The reader has to reach section 2 to see that concept presented.
• P5 Section 1.3: A few words telling who or what is usualy in charge of granting and revoking of access would clarify the scope of the standard
• P6 Section 1.4: I really appreciate that glossary! This should be an example for all of us.
• P8 section 2.2: It is said that With the help of an IVOA Registry, the system has all the information. This is an understatement. In my understanding, group IDs, based on IVOID, need the registry to be resolved; they would be useless otherwise.
• P8 section 2.2: 3 criteria are given to resolve group IDs (ivoid, standard_id and intf_role), as the text explictely mentions RegTAP, it would be nice to mention the table they come from in the bullet list. I'm speaking with the hat of one guy developping a registry explorer.
• P9 section 2.2: The caching issue tackles with the concern of the validity period which is an important point. That would justify to have a dedicated (sub)subsection.
• P10 section 3.1: I’m a bit confused with the concept of calling user, is that the service or the resource with a restricted access and which operates the authentication or is that the user connecting that service? Clients using this standard are actally servers, this may lose more than one reader. In my opinion, a flow chart would help to clarify the roles of the different stakholders.
• P13 section 3.3 : The second half of the section tells why a super-user role has been discard from the standard. I'm wondering whether a normative section is a good place for such a justification. It should be reduced at least.
• P14 section 4: Typo: correpondes -> corresponds

Approved

-- LaurentMichel - 2022-01-05

Thanks Laurent, good feedback. I've incorporated most of your comments into the pull request below. I've reduced the text on the super-user role to a few sentences in a paragraph.

https://github.com/ivoa-std/GMS/pull/22

-- BrianMajor - 2022-01-07

Grid & Web Services Working Group

This standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem.

As all the comments from the other WGs has been addressed I think we can approve it.

-- GiulianoTaffoni - 2022-01-22

Registry Working Group

Given the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved.

Minor copyediting in sec 3.1:
"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources?

"If an authenticated user could not be identitfied", typo "identified"

-- TheresaDower - 2021-11-16

• Thanks Theresa, I've fixed the typos. -- BrianMajor - 2021-11-19

Semantics Working Group

Semantics is unconcerned by the standard as far as I can see.

However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...

• Thanks Markus. Registry entries:
  • CADC: ivo://cadc.nrc.ca/gms
  • INAF: ivo://ia2.inaf.it/gms

-- MarkusDemleitner - 2021-09-13

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Radio Astronomy Interest Group

• RadioIG is not specifically concerned
• The specification looks well designed and written. It's quite understanble even for people unaware of such mechanisms.
• Typo 1 : page 4 section 1.1 ".... are using TAP to to access...."
• TYpo 2 : Page 9 section 2.2. strange writing for "either, .... or" in itemize.
• Typo 3 : Page 10 section 3.1 ".....who is subject of the of the membership question."

Solar System Interest Group

On the whole, this standard seems reasonable.

I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess.

Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed.

I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.

• Thanks (Baptiste?). I've make that suggested change. -- BrianMajor - 2021-11-02

Minor typos:

• Section 3.1, in the paragraph beginning "It is the authenticated user...": the words "of the" are repeated in the first sentence ("of the of the").
• Section 3.2, Example 1, first sentence: "...request from a user read a node..." should probably be "...request from a user to read a node..."
• Section 3.2, Example 1, paragraph beginning "After receiving this response, ...": "... a member of group allowed ..." should be "... a member of a group allowed..."
• Section 3.2, Example 3, example group list: I suspect the intention was for "my-thrid-collaboration" to be "my-third-collaboration"
• Section 3.3, second paragraph: There is an extra '.' in the parentheses: "(proxy certificate, token, etc..)"
• Section A.1, third bullet: "Update examples with to match..." should be "Update examples to match..."

Many thanks for the detailed read. I've corrected these typos. -- BrianMajor - 2021-11-02

Theory Interest Group

Time Domain Interest Group

Operations Interest Group

Looks good to me. Apart from comments already made by others, only a couple of minor typos to add:

• Sec 2.1: "a single entity than can be referenced" - should "than" read "that"?
• Sec 3.1: "services with proprietary (not users themselves)" - word missing after "proprietary"?
• Appendix A.1: "Update examples with to match API changes" - missing word?

-- MarkTaylor - 2021-09-22

Thanks Mark, I've made these corrections. -- BrianMajor - 2021-11-02

Standards and Processes Committee

TCG Vote

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group	Yes	No	Abstain	Comments
TCG	*
Apps	*
DAL	*
DM	*
GWS	*
Registry	*
Semantics	*			(once there are registered GMSes that are used some A&A machinery)
DCP
Edu
KDIG	*
Radio	*
SSIG	*			Typos included in comments
Theory
TD
Ops	*
StdProc