Group Membership Service Working Draft


Working Draft

The most recent published Working Draft can be found here: Group Membership Service

Comments from the community to be considered

  • The idea at the bottom of p9 is worth exploring... identity=x509:?? -- PatrickDowler - 2018-11-06

  • In the section describing possible future enhancements, specifically a way to manage groups, references should be made to the IETF RFCs 7642, 7643, and 7644, which make up the SCIM (System for Cross-Identity management). These RFCs were brought to my attention by MathieuServillat -- BrianMajor - 2019-03-22

Comments accepted and applied to the non-published version of the working draft

  • all currently in the published version

Comments accepted and applied to the latest, published working draft

  • Why the fixed /gms part of he path? Just to give the group uri scheme some recognisability? We could also go vospace style , eg gms://authority/path?group to get that but with simpler extraction if the resource ID... I think path restriction will rub people the wrong way. It really means it is hard to embed gms capabilities into other existing services where you already chose the resource id -- PatrickDowler - 2018-11-06
    • +1 for me on the gms:// schema solution. It leaves the local part of the IVOID (URI) opaque as it should and free-to-manage by the providers. -- MarcoMolinaro - 2018-11-07
      • I've changed the gms ivoid to be in the gms:// form suggested above. -- BrianMajor - 2019-03-22
      • This has been changed back to a IVOID (ivo scheme) but without a fixed path -- BrianMajor - 2019-04-26

  • I think user and principal are misleading param names; user is a collection of identities so maybe identity would be better. I'm not sure how the term principal is used outside the java APIs, but I would thing identiyType or idType would make this more clear.
    • The two optional parameters have been renamed 'identity' and 'identityType' . -- BrianMajor - 2019-03-22

  • Paraphrased from an email from MarkTaylor: the use of 403 as the response code to indicate non-membership doesn't seem correct.
    • I agree and have changed the API definition of GET to /search/groups/{group} to simply return an empty list of groups and 200 (OK) to mirror the API for GET to /search/groups -- BrianMajor - 2019-03-22

  • Paraphrased from an email from MarkTaylor: the existence of both a functional and REST definition of the GMS API is confusing.
    • Okay, thanks. I think I will put the API in tabular format instead and hopefully that will help clarify that section. -- BrianMajor - 2019-03-22

  • Corrections and edits to the Group Identifiers section including the registry lookup based on feedback from Mark Taylor and Marcus Demleitner. -- BrianMajor - 20190426

Topic revision: r9 - 2019-04-26 - BrianMajor
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback