Differences

This shows you the differences between two versions of the page.

--- open:wp4:aandanotes [2019/02/27 11:49]
molinaro [General report from contributions]
+++ open:wp4:aandanotes [2019/03/07 08:00] (current)
molinaro [Day 2 Morning Discussion]
@@ Line 134: / Line 134: @@
 First day open discussion report. This mainly touched the following topics:
   * data behind authentication
-  * labeling data resources for authenticated access
+  * filtering on private data and proprietary period considerations
-  * commercial cloud solutions and drawbacks
+  * commercial cloud concerns
-  * authenticator solutions, certificates, delegation, proxy modules
+  * interoperable authentication: metadata needs
+=== data behind authentication ===
+The discussion started from the question: what are the advantages and drawbacks of having data behind authentication?
+In terms of tooling and services CADC does not apply a distinction in the environment for public and private data. This is the reason that led to having VO standard based tooling behind of all this.
+However the IVOA ha generally been seen as the "public" data framework and one concern may still stay there in having authenticated services/resources because it could lead to no-release of data to the public without authenticating first.
+This is perfectly expressed by the statement (see Mark Taylor's presentation) that "many unautheticated shouldn't suffer from few authenticated ones".
+=== filtering on private data and proprietary period considerations ===
+The discussion continued on investigating on how one should label data resources for filtering based on authentication, whether it means allowing metadata to be in place and visible even if the actual data are private, what to do with tablesets and at what step authentication should step in.
+Along these line it was reported that DOI metadata must be public, while the actual data
+behind can be private.
+As for the length of proprietary period, it is clear that it depends on cases: shorter for telescope observations usually have longer detention period for project related data and, in multi-messenger scenarios, the data segregation may be used to limit collaboration anf avoid potential competition while reaching the publication goal.
+=== commercial cloud concerns ===
+Next topic dealt with the implications of using commercial clouds for sceintific research.
+One point was about the costs of this solution, not always easy to evaluate, in particular when comparing to institutional services whose costs may be hidden or difficult to quantify.
+Another was about how many risks to interoperability this will lead to if commercial interfaces take the lead on community standard developed ones.
+What is called "vendor lock in" can happen at any step, like making it unfeasible to retrieve resources that were easy and cheap to load into the cloud itself.
+One thing to check for sure is how much open standards are in place and guaranteed within commercial clouds (e.g. Amazon uses PostgreSQL based DBaaS).
+=== interoperable authentication: metadata needs ===
+As last topic of this section the attendees focused on trying to identify what metadata would be needed by the registry to allow client/server proper interoperable authentication.
+usually authenticators are human readbale interfaces.
+Discussion fell back into the solution in merging identities and credentials systems (e.g. certificates) and the idea of credentials translation services or proxy solutions.
+A proxy solution for interoperability would be having an organization committing in running a centralized access service to allow authentication.
 ===== Day 2 Morning Discussion =====
 The second day morning discussion was devoted to two specific issues:
-   * TAP-1.1 Authenticated endpoints
-   * ADQL-2.1 (& DALI) REGION xtype
+=== TAP-1.1 Authenticated Endpoints ===
+The discussion on the TAP-1.1 specification, directly related to its authenticated endpoints issue took start from the presentations of the morning of day 1.
+Reviewing mainly what was said there by the various stakeholders, it turned out that the agreeable solution would be staying on the ParamHTTP interface solution for TAP-1.1 and let the transaction to a better standard interface to the TAPRegExt recommendation revision (introducing the DALIInterface specification, to be written).
+The solution will require anyway an erratum to VOResource-1.1 to allow multiple securityMethod(s) and it will have some flow into the RegTAP-1.1 specification.
+A solution to allow anonymous authentication listed alongside other methods (or leaving it unspecified) was not found, it may need a change in SSO or some simple statements on best practices in the involved recommendations.
+=== ADQL REGION Discussion ===
+This discussion was meant to recover comments and decision about the wording to be used in ADQL-2.1 about the REGION function in connection with an xtype="region" in DALI (to fit into the DALI-1.2 revision).
+The discussion saw a review of the DALI-1.1-Next page that lists the basic requirements for new xtypes in DALI.
+Discussion focused mainly on the polymorphic and complex/disjoint shapes to be (or not) allowed to be described with the help of an xtype, given the primitive types and arrays cannot unambigously identify them.
+The ADQL related region (x)type falls in both the polymorphic and complex types, allowing union and intersection of analityic poligonals.
+The discussion touched many points and many connections also to other VO standards and, in particular, the real need for complex shapes when, for many discovery use cases, the tessellation solution may be a quicker choice.
+The discussion was not really conlusive on all the points and mainly saw an agreement in having in DALI-1.2 the region, shape and multiinterval xtypes and allow for a smooth path with this respect in ADQL-2.1.
 ===== Day 2 Afternoon Discussion =====
 The afternoon of the second day saw discussion upon:
-  * Credential Delegation in general
-  * Centralised authentication solutions
+=== Credential Delegation General Discussion ===
+The discussion in session 6 started with a panel overview on credential delegation, starting with questions like how the users can use their credentials to run the jobs, how to hide the users the complexity of moving their credentials around (like in the CADC proxy certificate solution), what do the users do need to know about their certificates and the CAs releasing them, what impact has this in their ability to use the certificates afterwards.
+It was again stated that a solution like the CADC one is what the users might find more confortable in having their research lives simplified. However the proxy certificates from CADC are not usable/interoperable outside the CADC environment.
+As an alternative to certificates OAuth tokens are largely gaining ground in authentication and authorization. They also can be re-used but it is consiedered unsafe because the longer they live, the higher tha chance that control on the token is lost. Thus, setting the scope of the token is a mandatory requirement (up to the level of single scoped tokens).
+Form the point of view of interoperability/delegation more work needs to be done on OAuth tokens and their delegation mechanism before having a clear view.
+There are however astrophysical research infrastructures investigating them (like LSST and STScI).
+On the general topic of credential delegation one concern is also about the delegation of credentials outside the institutional scope.
+Again the topic of programmatic access and federated or delegated authentication was arised, with a mention to the Shibboleth-ECP solution, that is, however, optional to SAML IdPs.
+Credentials linking/merging on the providers side is considered by most of the attendees the only way to be able to attach authorization properly to the resource-role relationship.
 ===== Datalink revision splinter =====

ASTERICS Wiki pages

User Tools

Site Tools

Differences

Page Tools