Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The Group Membership Service specifications fills the gap in interoperating authoritative services in the AuthN&AuthZ scenario of the IVOA Recommendations. It works on top of the group concept that collect autorization rights for singles or teams of users. GMS provides a simple API specification to cover the authorization checks when trying to access resources. The document has been fully reviewed by TCG. Approved -- JanetEvans, MarcoMolinaro - 2022-02-17 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest Group
Solar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest Group
Solar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest Group
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
Solar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest Group
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Solar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Solar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 Grid & Web Services Working GroupThis standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Thanks Laurent, good feedback. I've incorporated most of your comments into the pull request below. I've reduced the text on the super-user role to a few sentences in a paragraph. https://github.com/ivoa-std/GMS/pull/22 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks Laurent, good feedback. I've incorporated most of your comments into the pull request below. I've reduced the text on the super-user role to a few sentences in a paragraph. https://github.com/ivoa-std/GMS/pull/22 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- BrianMajor - 2022-01-07
Grid & Web Services Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | This standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem. As all the comments from the other WGs has been addressed I think we can approve it. -- GiulianoTaffoni - 2022-01-22 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
Registry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
Thanks Laurent, good feedback. I've incorporated most of your comments into the pull request below. I've reduced the text on the super-user role to a few sentences in a paragraph. https://github.com/ivoa-std/GMS/pull/22 -- BrianMajor - 2022-01-07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks James and Gregory. I have fixed the parenthesis typo and am working on updating the bibliography in github so that the citation resolves. -- BrianMajor - 2022-01-07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working GroupAlthough this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupThe spec is well written and conveys the requirements clearly. We have two minor edits:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- JamesDempsey - 2021-12-20
-- GregoryMantelet - 2021-12-20
Data Model Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Although this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The spec is well written and conveys the requirements clearly. We have two minor edits:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The latest version of the GMS Specification can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The original PR for the GMS Specification can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The updated draft GMS Specification (with some RFC points addressed) can be found on the github CI build: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupGiven the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved. Minor copyediting in sec 3.1:"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
-- AdrianDamian - 2021-10-29
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Given the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved.
Minor copyediting in sec 3.1: "Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary resources? "If an authenticated user could not be identitfied", typo "identified" -- TheresaDower - 2021-11-16 | ||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it.1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- AdrianDamian - 2021-10-29
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors?
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? 2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities). 3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).
3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- AdrianDamian - 2021-10-29
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Minor typos:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Many thanks for the detailed read. I've corrected these typos. -- BrianMajor - 2021-11-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks Mark, I've made these corrections. -- BrianMajor - 2021-11-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupThe document looks good over all. Here are some aspects that we feel could strenghten it. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? 2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities). 3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | 1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? 2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities). 3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- AdrianDamian - 2021-10-29
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The document looks good over all. Here are some aspects that we feel could strenghten it.
1. Group Name. The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not. IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)? 2. Group Identifier uniqueness. We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users. Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities). 3. GMS availability It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.
-- AdrianDamian - 2021-10-29 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}} | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- CarloMariaZwoelf - 2021-09-14
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupLooks good to me. Apart from comments already made by others, only a couple of minor typos to add:
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:
\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}} | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13
Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- CarloMariaZwoelf - 2021-09-14
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Looks good to me. Apart from comments already made by others, only a couple of minor typos to add: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Looks good to me. Apart from comments already made by others, only a couple of minor typos to add: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkTaylor - 2021-09-22
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" (2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. (4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. (6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? -- MarkusDemleitner - 2021-09-13 Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome (2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. (3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? -- CarloMariaZwoelf - 2021-09-14Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest GroupOn the whole, this standard seems reasonable. I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess. Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed. I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols. Minor typos:
Theory Interest GroupTime Domain Interest GroupOperations Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Looks good to me. Apart from comments already made by others, only a couple of minor typos to add:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" (2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. (4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. (6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? -- MarkusDemleitner - 2021-09-13 Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome (2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. (3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? -- CarloMariaZwoelf - 2021-09-14Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupRadio Astronomy Interest GroupSolar System Interest Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | On the whole, this standard seems reasonable.
I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess.
Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed.
I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.
Minor typos:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Theory Interest GroupTime Domain Interest GroupOperations Interest GroupStandards and Processes CommitteeTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" (2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. (4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. (6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? -- MarkusDemleitner - 2021-09-13 Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome (2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. (3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? -- CarloMariaZwoelf - 2021-09-14Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13 | ||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > | Data Curation & Preservation Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
Education Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||
< < | Time Domain Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
> > | Knowledge Discovery Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||
< < | Data Curation & Preservation Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
> > | Radio Astronomy Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > | Solar System Interest GroupTheory Interest GroupTime Domain Interest Group | |||||||||||||||||||||||||||||||||||||||||||||
Operations Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > | Standards and Processes Committee | |||||||||||||||||||||||||||||||||||||||||||||
TCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from IVOA community membersMarkus Demleitner | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Consequently, "lookup the document associated with .. in the registry; | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (2) p8 I think italicising RegTAP column names as you do when first | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | \definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | \definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (3) Your standard points to a deficiency in Registry I've long wanted to | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (4) I think you should say a word or two on how often the Registry | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (5) I'd be a lot more relaxed if there were at least one service with an | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (6) I've not thought deeply about that, but p.10's "If the user | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Carlo Zwölf(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome (2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level. (3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers? -- CarloMariaZwoelf - 2021-09-14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupSemantics is unconcerned by the standard as far as I can see. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | However, we are not quite happy with the demonstration of the reference | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2021-09-13 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Education Interest GroupTime Domain Interest GroupData Curation & Preservation Interest GroupOperations Interest GroupTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
| ||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||
< < | Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30 | |||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||
> > |
Comments from IVOA community membersMarkus Demleitner(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below". Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:" (2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect. (4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere. (5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later. (6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors? -- MarkusDemleitner - 2021-09-13 Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30 | |||||||||||||||||||||||||||||||||||
TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working Group | ||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||
> > | Semantics is unconcerned by the standard as far as I can see. However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec... -- MarkusDemleitner - 2021-09-13 | |||||||||||||||||||||||||||||||||||
Education Interest GroupTime Domain Interest GroupData Curation & Preservation Interest GroupOperations Interest GroupTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30
TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupEducation Interest GroupTime Domain Interest GroupData Curation & Preservation Interest GroupOperations Interest GroupTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
Reference Implementations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | TODO
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupEducation Interest GroupTime Domain Interest GroupData Curation & Preservation Interest GroupOperations Interest GroupTCG VoteIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<-- --> |
Group Membership Service: Request for Comments<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Reference ImplementationsTODO | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )Applications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupEducation Interest GroupTime Domain Interest GroupData Curation & Preservation Interest GroupOperations Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | TCG Vote | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | TCG Vote | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Revision 12021-08-23 - GiulianoTaffoni
|