Another GMS WD

[Brian Major]

Hi Markus, thanks for the comments.

On Thu, Apr 4, 2019 at 12:11 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Brian,
>
> On Wed, Apr 03, 2019 at 10:34:27PM +0000, Mark Taylor wrote:
> > a few comments on WD-GMS-1.0-20190329 as requested:
> >
> > On changing the IVOID scheme from ivo to gms:
> >    As I understand it, it's not an IVOID if it doesn't use the "ivo"
> scheme.
> >    IVOID 2.0 section 2.3.1 says: "The <scheme> part of IVOIDs is ivo.".
> >
> >    I think(?) that you should abandon the idea of syntactically
> signalling
> >    that an IVOID is a Group Identifier.  It's not necessary to do that
> >    anyway, that's properly signalled by context: an IVOID can be
> >    treated as a Group Identifier if a capability of its resource has
> >    standard_id="ivo://ivoa.net/std/gms#search-1.0" (er, or something
> >    like that).
> >
> >    Note that the examples in section 4.2 still use the ivo scheme
> >    in any case - at least usage has to be consistent.
>
> Yes, there shouldn't be any identifiers with a non-ivo scheme in the
> Registry for now.  I'm not saying we can't ever have any of these,
> but if they go in, we need a good plan and understand what that
> means.
>
> From what I understand of what you're doing here, I don't think
> there's a major reason to have that.  However, there *may* be a point
> to introduce a new URL scheme outside of the registry.  As follows:
>
> Essentially you're saying "to identify a group, use an identifier
> like gms://<authority>/<path>?<group>"; incidentally, while skimming
> the document I couldn't quite figure out where these group ids would
> actually show up in operation (a securityMethod in an interface?
> some sort of service response?).


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.


> Perhaps I've not read the document
> well enough, but if there's really nothing about that, that kind of
> information would help a lot, in particular for the TCG review that
> needs to look at implementations.
>

Yes, ok.  I will add some text to make it clear where group URIs are found.


>
> Anyway: the RegTAP query indicates that what ivo://<authority>/<path>
> points to is some sort of service with a capability with standardID
> ivo://ivoa.net/std/gms#search-1.0.


Yes.  But skipping the registry TAP query stuff for now...


> If you forsee a major use case where clients have to figure out up
> front whether an identifier is a group ID or something else, a gms:
> scheme would indeed be the way to go.


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://
ivoa.net/vospace/core#groupread (see
http://ivoa.net/documents/VOSpace/20180620/REC-VOSpace-2.1.html#tth_sEc3.2.4)
We have some proprietary table data exposed through TAP, in which case the
groupURI would be in a column titled something like 'readGroup'.

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.


> These gms URIs should still not get into the registry, and the GMS
> services should still have ivo URIs even in that case, though.  You'd
> have to have language like
>
>   To resolve a gms URI:
>
>   (a) take the authority and path part, form an IVOID with them,
>       and resolve that identifier in the registry to GMS service access
>       URL.
>
>   (b) take the query part of the GMS URI and issue a GET on the
>       discovered service's search/{group} endpoint.
>

That's correct.


>
>   For instance, gms://example.org/ingroup?punks would be resolved by
>   querying the Registry for a GMS endpoint of
>   ivo://example.org/ingroup and then retrieve <discovered
>   URL>search/punks.
>

Yes.  (And now I see why the example in the working draft is confusing and
wrong :)


> Given that, if you don't have a strong use case for going the extra
> schema route, my advice is to stay with ivo.
>

The extra schema route was chosen for the reason that VOSpace node URIs are
like that.  eg vos://cadc.nrc.ca!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.

(Skipping the resource-key / path discussion for now.)


> Oh, and I've committed some minor typographical changes in rev. 5379.
>

Thanks.


>
> Also, I notice you don't have the arch diagram yet.  If you tell me
> what you'd like GMS to be related with, I'm happy to quickly make one
> for you.
>

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?

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20190415/76ac246d/attachment.html>