<div dir="ltr"><div dir="ltr"><div>Hi Markus, thanks for the comments.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 12:11 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Brian,<br>
<br>
On Wed, Apr 03, 2019 at 10:34:27PM +0000, Mark Taylor wrote:<br>
> a few comments on WD-GMS-1.0-20190329 as requested:<br>
> <br>
> On changing the IVOID scheme from ivo to gms:<br>
> As I understand it, it's not an IVOID if it doesn't use the "ivo" scheme.<br>
> IVOID 2.0 section 2.3.1 says: "The <scheme> part of IVOIDs is ivo.".<br>
> <br>
> I think(?) that you should abandon the idea of syntactically signalling<br>
> that an IVOID is a Group Identifier. It's not necessary to do that<br>
> anyway, that's properly signalled by context: an IVOID can be<br>
> treated as a Group Identifier if a capability of its resource has<br>
> standard_id="ivo://<a href="http://ivoa.net/std/gms#search-1.0" rel="noreferrer" target="_blank">ivoa.net/std/gms#search-1.0</a>" (er, or something<br>
> like that).<br>
> <br>
> Note that the examples in section 4.2 still use the ivo scheme<br>
> in any case - at least usage has to be consistent.<br>
<br>
Yes, there shouldn't be any identifiers with a non-ivo scheme in the<br>
Registry for now. I'm not saying we can't ever have any of these,<br>
but if they go in, we need a good plan and understand what that<br>
means.<br>
<br>
>From what I understand of what you're doing here, I don't think<br>
there's a major reason to have that. However, there *may* be a point<br>
to introduce a new URL scheme outside of the registry. As follows:<br>
<br>
Essentially you're saying "to identify a group, use an identifier<br>
like gms://<authority>/<path>?<group>"; incidentally, while skimming<br>
the document I couldn't quite figure out where these group ids would<br>
actually show up in operation (a securityMethod in an interface?<br>
some sort of service response?). </blockquote><div><br></div><div>This is a good place to start. There's really only one sentence about this in the current WD: "They are attached to proprietary resources as grants.". Group URIs are out in the wild protecting proprietary resources. When code encounters a resource that says it can be accessed by a certain group (identified by the group URI), it then does the work of resolving the URI to a GMS service URL so it can make the "isMember" call. So, group URIs will not go in the registry. The GMS service that can answer the isMember question will go in the registry. It is this URL that needs to be determined from the group URI.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Perhaps I've not read the document<br>
well enough, but if there's really nothing about that, that kind of<br>
information would help a lot, in particular for the TCG review that<br>
needs to look at implementations.<br></blockquote><div><br></div><div>Yes, ok. <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I will add some text to make it clear where group URIs are found.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Anyway: the RegTAP query indicates that what ivo://<authority>/<path><br>
points to is some sort of service with a capability with standardID<br>
ivo://<a href="http://ivoa.net/std/gms#search-1.0" rel="noreferrer" target="_blank">ivoa.net/std/gms#search-1.0</a>.</blockquote><div><br></div><div>Yes. But skipping the registry TAP query stuff for now...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you forsee a major use case where clients have to figure out up<br>
front whether an identifier is a group ID or something else, a gms:<br>
scheme would indeed be the way to go.</blockquote><div><br></div><div>That is a good question. For the use of groups at the CADC so far, the groupURI is the value of well-named attribute attached to the resource. For example, in VOSpace the group URI goes in a Node property with a standardID identifying the access level, such as ivo://<a href="http://ivoa.net/vospace/core#groupread">ivoa.net/vospace/core#groupread</a> (see <a href="http://ivoa.net/documents/VOSpace/20180620/REC-VOSpace-2.1.html#tth_sEc3.2.4">http://ivoa.net/documents/VOSpace/20180620/REC-VOSpace-2.1.html#tth_sEc3.2.4</a>) We have some proprietary table data exposed through TAP, in which case the groupURI would be in a column titled something like 'readGroup'.</div><div><br></div><div>So, I can't really imagine a scenario where you'd have to figure out that it's a group authorization check you're trying to do with the URI--the context will be there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
These gms URIs should still not get into the registry, and the GMS<br>
services should still have ivo URIs even in that case, though. You'd<br>
have to have language like<br>
<br>
To resolve a gms URI:<br>
<br>
(a) take the authority and path part, form an IVOID with them,<br>
and resolve that identifier in the registry to GMS service access<br>
URL.<br>
<br>
(b) take the query part of the GMS URI and issue a GET on the<br>
discovered service's search/{group} endpoint.<br></blockquote><div><br></div><div>That's correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For instance, gms://<a href="http://example.org/ingroup?punks" rel="noreferrer" target="_blank">example.org/ingroup?punks</a> would be resolved by<br>
querying the Registry for a GMS endpoint of<br>
ivo://<a href="http://example.org/ingroup" rel="noreferrer" target="_blank">example.org/ingroup</a> and then retrieve <discovered<br>
URL>search/punks.<br></blockquote><div><br></div><div>Yes. (And now I see why the example in the working draft is confusing and wrong :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Given that, if you don't have a strong use case for going the extra<br>
schema route, my advice is to stay with ivo.<br></blockquote><div><br></div><div>The extra schema route was chosen for the reason that VOSpace node URIs are like that. eg vos://<a href="http://cadc.nrc.ca">cadc.nrc.ca</a>!vospace/path/to/node. The commonality is that groups, like nodes, are kind of like 'instances' of things within the service that handles them. They won't go in the registry. I don't think they need to explicitly note that they represent groups, but it can't hurt for readability and debugging.</div><div> </div><div>(Skipping the resource-key / path discussion for now.) </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Oh, and I've committed some minor typographical changes in rev. 5379.<br></blockquote><div><br></div><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, I notice you don't have the arch diagram yet. If you tell me<br>
what you'd like GMS to be related with, I'm happy to quickly make one<br>
for you.<br></blockquote><div><br></div><div>That would be a big help, thanks. I see that SSO and CDP are in the 'Using' section, but I can see GMS being associated with the 'Sharing' (of proprietary date) section too. Thoughts on this anyone?</div><div><br></div><div>Cheers,</div><div>Brian</div></div></div></div>