# Request for IDAC OIDC **URL:** \ **Category:** Independent Data Access Centers\ **Created:** [February 26, 2026, 6:00pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641 "2026-02-26T18:00:35Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [February 26, 2026, 6:00pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/1 "2026-02-26T18:00:36Z")
@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/](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/](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. ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [March 11, 2026, 6:01pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/2 "2026-03-11T18:01:57Z")
Hello, I’m updating this thread to see what next steps we might need to take to qualify. Cheers and thank you, Alec ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [March 11, 2026, 9:02pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/3 "2026-03-11T21:02:55Z")
Hi Alec, Can you indicate which IDAC you’re representing, and give some background on it? Thanks, Knut Olsen ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [March 11, 2026, 9:19pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/4 "2026-03-11T21:19:26Z")
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. ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [March 11, 2026, 11:16pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/5 "2026-03-11T23:16:31Z")
Hi again, So you might have a look at this pair of documents: [https://rtn-003.lsst.io](https://rtn-003.lsst.io) – Guidelines for IDACs and [https://rtn-086.lsst.io](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](https://www.lsst.org/scientists/in-kind-program/computing-resources). 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 ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [March 12, 2026, 1:03pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/6 "2026-03-12T13:03:52Z")
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 ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [April 1, 2026, 3:28pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/7 "2026-04-01T15:28:44Z")
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? ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [May 27, 2026, 7:08pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/8 "2026-05-27T19:08:59Z")
Hi @knutago , 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](http://www.rubin.community/t/authentication-setup-for-in-kind-data-sharing/11268)). 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. Thank you, Alec ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [June 17, 2026, 10:24pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/9 "2026-06-17T22:24:19Z")
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 ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [June 18, 2026, 3:15pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/10 "2026-06-18T15:15:07Z")
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. ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [June 18, 2026, 5:40pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/11 "2026-06-18T17:40:06Z")
Thanks for understanding, and we should definitely revisit after the churn of the data previews has subsided. ---
**Author:** ![mschwamb](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mschwamb/32/3007_2.png) [@mschwamb](https://www.rubin.community/u/mschwamb)\ **Post date:** [July 28, 2026, 10:30am UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/12 "2026-07-28T10:30:18Z")
Given the discussion at the RCW yesterday, this request seems similar to this [one by @mjuric](http://www.rubin.community/t/request-for-rubin-oidc-client-registration-for-solar-system-added-value-service/12323). @knutago , @frossie , and @rra could you take a look at this request again? Thanks. ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [July 28, 2026, 3:52pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/13 "2026-07-28T15:52:02Z")
I will revisit with @frossie The one possible hangup is that generating the cutouts involves data transfer, and need to check with her that the throughput rate could be throttled if the number of requests were large. It’s a bit more involved than just verifying data rights. ---
**Author:** ![alec\_b612](https://avatars.discourse-cdn.com/v4/letter/a/a698b9/32.png) [@alec\_b612](https://www.rubin.community/u/alec_b612)\ **Post date:** [July 28, 2026, 4:06pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/14 "2026-07-28T16:06:24Z")
Thank you for revisiting this! I could be wrong, but rate throttling would already be required because these resources will be available via API (e.g. TAP) using an RSP access token in regular 1st party use. ---
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [July 28, 2026, 8:35pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/15 "2026-07-28T20:35:08Z")
Just to clarify (as I chatted with @frossie about this briefly yesteday): @alec_b612 & co.'s request here is to enable the user to get a cutout of potential asteroid discovery, from their web browser. This isn’t a bulk operation, and is functionally equivalent to the user doing the same from the RSP Portal (but just integrated with a bunch of useful SolSys tools). Their system – [ADAM Precovery Service - Historical Observation Recovery | ADAM Demos](https://b612.ai/adam-platform/precovery/) – already does the same for other NOIRLab holdings (IIRC, via NOIRLab’s [SIAP](https://datalab.noirlab.edu/docs/manual/UsingAstroDataLab/WebPortal/DataExplorer/ImageSearchCutout/ImageSearchCutout.html) service). So from the PoV of the load, this should be equivalent to someone using the RSP. (one note: I know of a few groups who plan to do precovery-at-scale by writing Python scripts which if written w/o care could hit the RSP APIs in bulk-ish ways… a service such as this may remove the need for folks to write such hacks on their own.) ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [July 28, 2026, 10:57pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/16 "2026-07-28T22:57:26Z")
Ok, good to know. I’m meeting with @frossie next week to discuss ---
**Author:** ![mschwamb](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mschwamb/32/3007_2.png) [@mschwamb](https://www.rubin.community/u/mschwamb)\ **Post date:** [September 17, 2026, 8:37am UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/17 "2026-09-17T08:37:17Z")
@knutago Circling back to this. Any progress on the IDAC OIDC for the Asteroid Institute/B612 folks? ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [September 17, 2026, 8:18pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/18 "2026-09-17T20:18:42Z")
@mschwamb So SQuARE remain concerned about potential impact of external services generating data through the RSP and re-serving to the community. @frossie is putting thoughts into a tech note on this topic. We now have several IDACs that are associated with independently hosted data and computing infrastructure connected with client credentials; I think once the impact (or not) of supporting these becomes more clear, it will be easier to consider the request that the Asteroid Institute is making. ---
**Author:** ![mschwamb](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mschwamb/32/3007_2.png) [@mschwamb](https://www.rubin.community/u/mschwamb)\ **Post date:** [September 18, 2026, 12:37pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/19 "2026-09-18T12:37:10Z")
I think the benefit of this service would be that you don’t have the scenario that @mjuric highlighted. > I know of a few groups who plan to do precovery-at-scale by writing Python scripts which if written w/o care could hit the RSP APIs in bulk-ish ways… a service such as this may remove the need for folks to write such hacks on their own.) Given there is no tool/serviced provided on the RSP to generate cutouts based on orbital ephemerides predictions, having many groups doing this in bulk with bespoke python scripts may be more of a strain on the Rubin services. Is there a potential for this service to not go through the RSP but an IDAC to retrieve the cutouts. Would that help potentially mitigate some of the concern? ---
**Author:** ![knutago](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/knutago/32/602_2.png) [@knutago](https://www.rubin.community/u/knutago)\ **Post date:** [September 18, 2026, 7:01pm UTC](https://www.rubin.community/t/request-for-idac-oidc/11641/20 "2026-09-18T19:01:02Z")
These are good points. Interesting thought to have an IDAC handle this; I will look into it, but since it will require the IDAC to store the single visit images, the only candidate would be the UK IDAC. Stay tuned…