Request for IDAC OIDC

Science Independent Data Access Centers
#1

@rra @frossie

Hi Rubin team,

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:

  1. adam-api-rubin-prod
    Redirect URI: https://adam-api.app.b612.ai/api/users/rubin/link/callback/
  2. adam-api-rubin-dev
    Redirect URI: https://adam-api-oidc.dev.b612.ai/api/users/rubin/link/callback/

We’ll route local developer testing through that single dev callback host, so two client credentials should be sufficient.

Please confirm this setup is acceptable, and if there are specific required scopes/claims you want us to rely on for entitlement checks.

Thanks.

#2

Hello,
I’m updating this thread to see what next steps we might need to take to qualify.

Cheers and thank you,
Alec

#3

Hi Alec,

Can you indicate which IDAC you’re representing, and give some background on it?

Thanks, Knut Olsen

#4

Sure, I represent Asteroid Institute at the B612 Foundation. We are requesting to become an authorized IDAC.

I am happy to provide whatever information is requested. I could not locate an official process in the documentation.

#5

Hi again,

So you might have a look at this pair of documents:

https://rtn-003.lsst.io – Guidelines for IDACs
and
https://rtn-086.lsst.io – Bulk data transfer policies and procedures.

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.

Cheers Knut

#6

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.

  • Alec
#7

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 this the correct solution or is there another?