From jesus.salgado at skao.int Thu Jul 3 15:37:15 2025 From: jesus.salgado at skao.int (Salgado, Jesus) Date: Thu, 3 Jul 2025 13:37:15 +0000 Subject: DSP Running Meeting: Review of IVOA Authentication Protocol Draft Message-ID: Dear colleagues, We would like to propose a DSP Running Meeting dedicated to reviewing the current status of the IVOA Authentication and Authorisation Protocol (AuthVO) draft. Over the past months, the authors have defined several methods to access secure VO resources and we?ve made significant progress on integrating OAuth 2.0 into the IVOA framework, including discussion around bearer token usage, error handling, discovery mechanisms, and potential support for various client flows. However, several points still deserve collective discussion and agreement to ensure the protocol meets both practical implementation needs and our interoperability goals. Meeting Goals: * Review the latest AuthVO draft text and technical details * Discuss any remaining open issues or concerns from authors and reviewers * Align on potential future work Best Regards, Jesus Salgado & Sara Bertocco (DSP chairs) on behalf of Mark Taylor et at (AuthVO authors) The SKA Observatory is an inter-governmental organisation and the successor of SKA Organisation, a private limited company by guarantee registered in England and Wales with registered number 07881918, with a registered office of Jodrell Bank Observatory, Lower Withington, Macclesfield, Cheshire, England, SK11 9FT. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please inform the sender, and immediately and permanently delete the email. Do not use, copy or disclose the information contained in this message or in any attachment. This email has been scanned for viruses and malware, and may have been automatically archived, by Mimecast Ltd. Although SKA Observatory and SKA Organisation have taken reasonable precautions to ensure no viruses are present in this email, neither SKA Observatory nor SKA Organisation accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and attachments) are virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2547 bytes Desc: not available URL: From SVoutsinas at lsst.org Wed Jul 16 19:00:10 2025 From: SVoutsinas at lsst.org (Stelios Voutsinas) Date: Wed, 16 Jul 2025 17:00:10 +0000 Subject: Allowing optional extended fields in UWS job listings Message-ID: Hello all, I'd like to raise a question I've also posted as an issue to the UWS repo here: https://github.com/ivoa-std/UWS/issues/5 The current UWS spec limits job listings (/{jobs}) to basic fields in ShortJobDescription (phase, runId, ownerId, creationTime, id). Essential information like the query text or start/end time, and parameters requires separate API calls to /{jobs}/{job-id}, creating N+1 query patterns that hurt performance for clients that may want to use the job list to display a user's query history. This basically leads clients to have to decide between showing incomplete job lists or making individual job requests for every job in the list to display meaningful information that helps user identify a job. My proposal is to extend the specification to optionally include additional fields from JobSummary in job listings. This could be implemented through optional schema elements, or if for some reason that breaks compatibility for clients, perhaps an alternative could be using query parameters (GET /{jobs}?include=startTime,endTime,parameters). This would allow clients to use the job listing endpoint as a source of a user's job history and do so efficiently without requiring extra hops to gather additional metadata that is critical to identify each job. The motivation for this is that we use the job listing as a way of providing a user their TAP query history, but have found that the way the current job list schema is specified we have to make the additional HTTP hops for each job which leads to significant traffic increase to our server as the number of users starts to scale up. Any thoughts on this? Stelios Voutsinas -------------- next part -------------- An HTML attachment was scrubbed... URL: From msdemlei at ari.uni-heidelberg.de Thu Jul 24 09:34:32 2025 From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner) Date: Thu, 24 Jul 2025 09:34:32 +0200 Subject: Allowing optional extended fields in UWS job listings In-Reply-To: References: Message-ID: <20250724073432.ormarg22tsbspat2@victor> Dear Colleagues, On Wed, Jul 16, 2025 at 05:00:10PM +0000, Stelios Voutsinas via dsp wrote: > My proposal is to extend the specification to optionally include > additional fields from JobSummary in job listings. This sounds like an eminently understandable thing to want, and retrospectively I wonder why ShortJobDescription was introduced in the first place, since even the JobSummary-s will be rather compact. And if you actually have millions of jobs, where the size difference might matter, you would want some paging interface whether or not you have JobSummary-s or ShortJobDescription-s. Well, there *is* one aspect: I think the ShortJobDescription-s are, in principle, universally shareable (so you *could* show everything a service has in its queue in {async}), whereas I suspect many of our users would not be comfortable having their JobSummary-s public (which, full disclosure, they are with DaCHS' UWS as long as people do not authenticate). In practice, I don't think that's an issue: I'd be surprised if there was a UWS server-side implementation that shows everything on {async} to authenticated users and then only starts access control at the job level. > This could be implemented through optional schema elements, or if > for some reason that breaks compatibility for clients, perhaps an > alternative could be using query parameters (GET > /{jobs}?include=startTime,endTime,parameters). *In theory* , clients ought to ignore elements they don't know, so somehow extending uws:ShortJobDescription should work if clients are implemented by the book. I'd expect you'd be seeing warnings, but that doesn't hurt too much. However, for aesthetic reasons I can't say I like the idea of pulling stuff from JobSummary into ShortJobDescription. Let's not duplicate such things without dire need. I also like client control over responses, because that allows (relatively) safe extensions. So... what about defining a new element uws:jobSummaries and saying that {async} returns uws:jobs by default, but clients may pass in a GET parameter ?summaries=1 and then *may* get a uws:jobSummaries element back? Re-reading this, I'm not too fond of that either, because in the VO, we have this somewhat odious but *soooo* convenient habit of generally treating GET and POST analogously, and so defining different semantics for parameters per method (which we'd do in that way) sets a precendent that we perhaps don't want to set. So... what if we had a separate endpoint? You'd have {async} to POST to and pull uws:jobs from, and you'd have a job-summaries (probably literally named that) sibling endpoint to pull job summaries from. I'd probably even make that mandatory for UWS 1.2 so clients can rely on it once they have established a minimum version server-side. Opinions? -- Markus