Group Membership Service WD next steps

[Brian Major]

Dear GWS,

At the interop in Groningen I presented the current state of the Group
Membership Service (GMS) working draft.  In that presentation I explained
how a decision on the inclusion of the "identity" parameter was necessary,
what the important factors are to consider, and what the inclusion of the
parameter would likely entail.  I'll summarize that information here.

We would like to hear your opinions on this so we can work toward moving
this to RFC.

The slides explaining the situation are here:
https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DAL/GMS.pdf

But I'll explain it again in this email so we can discuss.

The minimal REST API to GWS to support interoperable authorization is this:

GET to /gms/search  -  to get the list of groups for which "the user" is a
member
GET to /gms/search/{groupURI} . -  check to see if "the user" is a member
of the group identified by {groupURI}.

Where "the user" is the subject of the membership inquiry.  (referred to
now as the "subject")

The WD describes two methods of identifying the subject:

    1.  From the identify of the user making the call to the API, according
to one of the supported authentication mechanisms in SSO 2.0.
    2.  From the identity conveyed by the (currently optional) API
parameters "identity" (and "identityType" -- see below [1]).

In the current WD, support for method 1 is mandatory and recommended for
two reasons:

    A.  Information privacy -- who (besides the subject) should be allowed
to see group membership information?  It probably should not be public
information, which implies only a certain set of privileged users should be
allowed to use the identity parameters (method 2).   (More on this is in
the slides.)

    B.  Avoiding inter-institute trust arrangements -- Following reason A:
If a GMS implementation only supports method 2, the list of 'privileged
users' from other institutes whom are allowed to call GMS would have to be
identified and maintained.  This arrangement is essentially a trust
relationship between centres.  In this scenario, a GMS client would not be
able to dynamically look up a GMS service in the registry and use it
without first having an agreement in place.

GMS is of most use by other services that have resources that are only
available to members of a certain group.  Thus, to use method 1, these
services must be able to act on behalf of their calling users.  This is
achieved by the processes described in the Credential Delegation Protocol
(CDP).  [2]

So, what should be the stance on these two approaches?

Interoperability between institutes implementing only method 2 can probably
not be achieved "at runtime" (because of information privacy) without
predefined trust arrangement.  Although, once in place, the standard
protocol becomes useful.

Method 1 requires that client services of GMS employ CDP.

Perhaps the current state of the WD is correct?  It says:  Method 1 is
mandatory and recommended.  Support for method 2 is optional.  Client
services must implement CDP.

Finally, if method 2 remains in the WD (optional or not), the
representation of identities that are to be in the 'identity' parameter
would be exposed in the API and thus need to be fleshed out.  That
standardization (in my opinion [3]) would need to go into a different
document.  The document would describe a simple identity model,
serialization, and perhaps a schema.  Thoughts on this would be appreciated
as well.

Thanks for reading.  Regards,
Brian


[1]  If we choose to support the identity and identityType parameters they
will be consolidated into a URI where the schema conveys the type of
identity being described.  Something like "token:kjd87aj2ljg8lhs" or
"x509:cn=user,ou-=university,c=canada".

[2]  Current CDP REC version 1.0 is based on X.509, but there seems to be
agreement that support for OAuth2 tokens could be added in the next version.

[3]  The experience of building other standards has shown that it is wise
to separate the model from the services so they can evolve separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20191017/e6ac8633/attachment.html>