We reviewed RTN-003 and related authentication/authorization guidance (including DMTN-253), and we’re implementing our cutout workflow to be compliant for proprietary Rubin data access as an IDAC.
At a high level, we are:
enforcing authenticated access with org context,
requiring Rubin-linked user identity/entitlement checks for proprietary cutout access,
ensuring proprietary cutout outputs are not exposed publicly.
Could you please register two OIDC clients for us:
IDACs are generally expected to be centers designed to serve broad segments of the Rubin community, and commit to some requirements as laid out in RTN-003. You can see the list of IDACs here: Contributed Computing Resources | Rubin Observatory.
As the B612 Foundation, you may be intending to serve mainly the Solar System Science Collaboration, which is ok, but would fall in the ‘Tier 2’ data transfer priority per RTN-086. At the moment, we’re still working on getting data transfer processes set up for the IDACs listed above, as well as a couple of institutions in the US that are serving a large segment of the Rubin community. It may be a little while before we could work with you to set up data transfers, if you are in this category.
If your intent is to serve a smaller group than a science collaboration, this would fall into Tier 3, and we would ask you to hold on for now.
Hi Knut,
Thanks for the guidance and for pointing us to RTN-003 and RTN-086.
To clarify our immediate ask: we are not requesting bulk transfer or mirrored release copies at this stage. We are specifically trying to support on-demand access to proprietary exposures/cutouts for existing Rubin data-rights holders, with strict access controls and no public redistribution. Our understanding is that the only correct way to do this currently is via the IDAC route.
Our near-term request is therefore for IDAC-style authentication integration (OIDC client pre-registration), not RTN-086 bulk-transfer onboarding. We intend to enforce Rubin-linked identity and data-rights checks per user before serving any proprietary data.
Let me know the correct path here, happy to put in the work.
I was hoping to follow up here given that the only need we have is for OIDC client credentials and not the bulk data transfer. The IDAC route seems like the correct designation given what we want to do, even if it is not the typical meaning of an IDAC:
Fetch exposure cutouts on behalf of other Rubin data rights holders, hosted them in a cache
Verify Rubin data right holder identities through the OIDC
No requirement for bulk data transfer or mirroring
Is there someone I could reach out or a place to submit a ticket to formally request OIDC credentials?
I see another party is looking to use OIDC for in-kind data sharing here (Authentication setup for in-kind data sharing). Our setup is even simpler: We want other data rights holders with RSP credentials to be able to fetch and view cutouts in our application.
Hi Alec,
Apologies for this very slow reply, I missed the notifications that there was further activity in the thread. So you are looking to create image cutouts through the USDAC, which you will then serve further to Rubin data rights holders? I think this still falls in the category below IDACs for support. I’ve talked to the Science Platform team about whether they can support this, and they have responded that third-party services such as this are beyond their ability to support in the data preview phase. But will keep this in mind for future.
Knut
Thanks for the reply and for communicating our request! It’s disappointing, but I understand priorities have to be set and really appreciate all the hard work happening behind the scenes. We are happy to revisit when possible.
Your description is accurate. To reiterate, I believe all we need mechanically is OIDC credentials. The second component is only permission to use OIDC that way.