<div dir="ltr">Dear GWS,<div><br></div><div>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 &quot;identity&quot; parameter was necessary, what the important factors are to consider, and what the inclusion of the parameter would likely entail.  I&#39;ll summarize that information here.</div><div><br></div><div>We would like to hear your opinions on this so we can work toward moving this to RFC.</div><div><br></div><div>The slides explaining the situation are here:  <a href="https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DAL/GMS.pdf">https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DAL/GMS.pdf</a></div><div><br></div><div>But I&#39;ll explain it again in this email so we can discuss.</div><div><br></div><div>The minimal REST API to GWS to support interoperable authorization is this:<br><br></div><div>GET to /gms/search  -  to get the list of groups for which &quot;the user&quot; is a member</div><div>GET to /gms/search/{groupURI} . -  check to see if &quot;the user&quot; is a member of the group identified by {groupURI}.</div><div><br></div><div>Where &quot;the user&quot; is the subject of the membership inquiry.  (referred to now as the &quot;subject&quot;)</div><div><br></div><div>The WD describes two methods of identifying the subject:</div><div><br>    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.</div><div>    2.  From the identity conveyed by the (currently optional) API parameters &quot;identity&quot; (and &quot;identityType&quot; -- see below [1]).<br></div><div><br></div><div>In the current WD, support for method 1 is mandatory and recommended for two reasons:</div><div><br></div><div>    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.)</div><div><br></div><div>    B.  Avoiding inter-institute trust arrangements -- Following reason A:  If a GMS implementation only supports method 2, the list of &#39;privileged users&#39; 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.<br><br>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]</div><div><br>So, what should be the stance on these two approaches?</div><div><br></div><div>Interoperability between institutes implementing only method 2 can probably not be achieved &quot;at runtime&quot; (because of information privacy) without predefined trust arrangement.  Although, once in place, the standard protocol becomes useful.</div><div><br></div><div>Method 1 requires that client services of GMS employ CDP.</div><div><br></div><div>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.</div><div><br></div><div>Finally, if method 2 remains in the WD (optional or not), the representation of identities that are to be in the &#39;identity&#39; 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.</div><div><br></div><div>Thanks for reading.  Regards,</div><div>Brian</div><div><br></div><div><br></div><div>[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 &quot;token:kjd87aj2ljg8lhs&quot; or &quot;x509:cn=user,ou-=university,c=canada&quot;.<br><br>[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.</div><div><br></div><div>[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.</div></div>