Group Membership Service: Request for Comments

Public discussion page for the IVOA GMS 1.0 Proposed Recommendation.

The latest version of the GMS Specification can be found at:

• PR-GMS-1.0-20210609

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

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:"

(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}}

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

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

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

(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?

-- MarkusDemleitner - 2021-09-13

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

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

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

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

-- MarkusDemleitner - 2021-09-13

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

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.