ivoa-std / gms Goto Github PK

As requested by Carlo Zwölf in the GMS RFC Page: Would be nice to have a comparison to related initiatives, such as:

refeds: https://refeds.org/

TBD

fim4r: https://fim4r.org/

TBD

oauth2: Often asked about this but GMS and OAuth2 are not solving the same problem:

GMS provides a way of performing dynamic runtime authorization checks in a variety of circumstances.

OAuth2 is more along the lines of CDP: It enables the end user to grant a service access to the user's resources.

@zonia3000 - This issue represents the task of putting the INAF GMS service record in the registry.

Does anyone know how to make the ivoatex link go to HEAD rather than a specific commit (as it is currently set)? I'm not sure where this link is managed. There are updates to the bibliography that I need to pull in.

At the moment, you're telling people to look for GMS services with the
constraint

AND standard_id = ’ivo://ivoa.net/std/gms#search-1.0’

That is almost certainly a bad idea, because that way when version 1.1
comes along, you either have to keep the 1.0 endpoints around (which
should not be necessary for minor version changes) or you'll break all
clients trying to resolve the group ids in the proposed way (which must
not happen for minor version changes).

There are a few ways out:

(a) you could tell people to ignore the minor version in discovery:

AND standard_id LIKE ’ivo://ivoa.net/std/gms#search-1.%’

That's nice because you could still figure out the minor version from
the registry record, but it kind of sucks because people will forget the
RE match and then you'll randomly break clients as you update the key.
Another advantage might be that that matches our current "best
practices" as of Identifiers 2.0. But then these seem less and less of
a good idea as we actually start having standards in multiple minor and
major versions.

(b) you could use the key "search-1". That would be constant for all
version 1 services. The disadvantage is that it's harder to figure out
the minor version of the service where that matters. If it turns out
that's necessary, you could use interface/@Version, though.

(c) honestly, I'd argue quite strongly that if there's ever a major
version 2 of GMS, it'll get a StandardsRegExt entry of its own, say,
ivo://ivoa.net/std/gms2. If you agree with that estimate, you could
just use ivo://ivoa.net/std/gms#search and drop all versioning
information from the symbol. Which would be nice, but of course makes
things a lot more implicit (though interface/@Version can still be used
to declare the complete version).

After the experiences of the last years, I'd tend towards (c), frankly;
plan (a) was courageous, but it puts quite a bit of load on implementors
and DB RE engines. Too much in the first case, I'm coming to think.
But then plan (a) is still sort-of endorsed.

Hm.

As raised by Adrian on the RFC page, the details of what constitues a valid group name should be stated. Are the case sensitive? What characters can be used? At CADC, the rules are:

They are case sensitive and allow alphanumerics and the characters -, ,, ., _, and ~.

As raised by Adrian on the RFC page, a note should be added stating that GMS availability is important because it is often in the path of many services with proprietary information.

Give no details on authentication and refer to latest version of SSO.

During the GMS RFC review session at the interop It was suggested that:

1. The specification should clearly state that clients of GMS should consider caching the mapping of resource identifiers to access URLs. The purpose of this is to avoid using RegTAP in a high transactional service. This is mostly there in the specification now after @msdemlei first raised the issue on the RFC page.
2. The specification should clearly state that clients of GMS should consider caching users' group membership information. The purpose of this is to allow clients to respond to requests when the target GMS service is temporarily unavailable.
3. GMS services could provide extra information on each call that would give clients an idea of long the membership results should be considered valid. This could be achieved by returning one or two timestamps, such as expiresAt. Clients could use this information to determine when their membership cache for a given user needs to be refreshed.

The current response from a call to //search is in simple plain/text format with the list of group names representing the user's memberships. So, there isn't currently a place in the response body to convey timestamps.

However, the HTTP response header Expires might be the best fit. (See section 14.21 here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). It essentially would convey the date when the group membership information should no longer be considered accurate.

As stated by Adrian on the RFC page, a GMS service should not allow group identifiers to be reused in case there are 'grants' on resources that are unknown. If a new set of users become members of a deleted group they would accidentally inherit authorization to those resources.