Group Membership Service WD next steps

[Giuliano Taffoni]

Dear Brain,
It is a pity there was not much discussion after Groenigen Interop on this topic. I know I am late, but I would like to share with you some thoughts on the WD.

I am in favour of Method 1, not only it solves some privacy issues, but also it is more integrated with the IVOA overall architecture (or at least with the SSO, CDP architecture). Not to mention that it is also simpler to implement.

In practice, I expect that on Site A a user delegates its credential to a service that then contacts a GMS on Site B. The GMS extracts from the CDP (actually X509 based) the identity (dn) and authorizes the service to search for groups.
That means that the GMS at site B is aware of the user identity to proceed with the authentication. Am I right?

I am a bit sceptical in implementing (or proposing ) a standard that requires a predefined trust arrangement, so method 2.
Then it is not clear to me is what happens  if we keep Method 2  as it is (i.e. optional), should we provide anyway the identity and the identityType which as you said it is not part of this specific document?
On the other side, if we rely on CDP identity, it is mandatory to start working on a new CDP standard that provides support also for other methods than X.509. And in my opinion, this is where we should put some efforts.

So I am in favour of:
Method 1 is mandatory and recommended and only
Client services must implement CDP.
We work to extend  CDP capabilities (who? :-) )

Any other ideas?
Regards
G.




> On 17 Oct 2019, at 18:54, Brian Major <major.brian at gmail.com> wrote:
> 
> 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.