open:wp4:aandanotes
Differences
This shows you the differences between two versions of the page.
|
open:wp4:aandanotes [2019/02/27 11:54] molinaro [Day 2 Morning Discussion] |
open:wp4:aandanotes [2019/03/07 08:00] (current) molinaro [Day 2 Morning Discussion] |
||
|---|---|---|---|
| Line 167: | Line 167: | ||
| === TAP-1.1 Authenticated Endpoints === | === TAP-1.1 Authenticated Endpoints === | ||
| - | The discussion on the TAP-1.1 specification, directly related to its authenticated endpoints issue took start from the presentation of the morning of day 1. | + | 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 agrreable 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. | + | 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 VOResuorce-1.1 to allow multiple securityMethod(s) and it will have some flow into the RegTAP-1.1 specification. | + | 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 simple statements on best practices in the recommendations. | + | 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 === | === ADQL REGION Discussion === | ||
| Line 183: | Line 183: | ||
| The afternoon of the second day saw discussion upon: | 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 ===== | ===== Datalink revision splinter ===== | ||
open/wp4/aandanotes.1551264863.txt.gz · Last modified: 2019/02/27 11:54 by molinaro
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
