Group Membership Service 1.0 WD

[Mark Taylor]

Brian,

On Fri, 2 Nov 2018, Brian Major wrote:

> We are pleased to announce the posting of the first version of a Group
> Membership Service working draft.  You can find a link to the WD and a
> place to submit comments here:
> 
>     http://wiki.ivoa.net/twiki/bin/view/IVOA/GroupMembershipService
> 
> Looking forward to hearing your feedback and talking about it at College
> Park.

in general, the GMS document looks fine to me, but I have a couple of
comments about section 4.1.


First, the the "search API" defines two functions:

   boolean isMember(Group, User)
   list<Group> getMemberships(User)

and these are implemented by the REST API under the endpoints:

   GET /search/{group}
   GET /search

Unless I'm misunderstanding what's going on here (possible),
it seems a bit unnecessarily confusing to give these completely
different names in the abstract API and the REST interface.
Would it be better to homogenise them a bit, e.g.

   GET /gms/isMember/{group}
   GET /gms/getMemberships

or something?  Not necessarily those names, but you get the idea.
Just a thought.


Second, the way in which HTTP return codes are used to communicate
results seems slightly fishy.

The text says:

   "An HTTP GET to /search/{group} shall respond with HTTP 200 (OK) if
    the user is a member of the {group}. If the user is not a member of
    the group, or if the user is not recognized, or if the group is not
    recognized, the service shall respond with HTTP 403 (Forbidden)."

This looks funny to me, since the request is to find out whether
a given user is a member of a named group, and a positive or
negative answer is being given - in the case of no membership,
the request about membership is not being forbidden (403) it's
just being answered in the negative.  The forbidden-ness doesn't
really apply to this response, just to the responses that a user
with the given identity might expect if s/he tries to do something
auth-sensitive in the future.

Moreover, RFC2616 section 10.4.4 says this about the 403 Forbidden
response code:

   "The server understood the request, but is refusing to fulfill it.
    Authorization will not help and the request SHOULD NOT be repeated."

But in the case of this endpoint, authorization might help, since
in the case where the request specifies the queried user's identity
implicitly (i.e. no user/principal request parameters supplied),
resubmitting the request with different credentials would
constitute a query about a different user, so might very well
give a different result.

So, maybe communicating the result using the (text/plain?) payload
of a 200 response might be more appropriate than communicating
the result using the HTTP response code.


Disclaimer: I'm not too familiar with other standards in this area,
so it may be that the things I'm complaining about are in fact
common usage for this kind of API.  If so, feel free to ignore!

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/