igtf-oidcfed October 2017

igtf-oidcfed@nikhef.nl

4 participants
3 discussions

OIDC Fed for Infrastructures ACAMP session resutls
by David Groep 19 Oct '17

19 Oct '17

Dear all, Yesterday at the "ACAMP" (un)conference at the I2 TechEX we had a very useful discussion on how to build a practical OIDC Federation for Reseaerch and e-Infrastructures, the requirements, scope of such a federation, and how to technically implement and operate it. Thanks to Roland (who was there and - for those of you who don't review list membership daily is now also on the list) there is a good amount of reference software tools to implement the concepts, and the rest we can easily add using standard operational tools. it was a very fruitful discussion, and Heather Flanagan was kind enough to take notes during the breakout. The notes are linked to the Wiki page at https://wiki.eugridpma.org/Main/OIDCFed and directly at https://wiki.eugridpma.org/pub/Main/OIDCFed/ACAMP2017-Wednesday-3_50pm-OIDC… We also discussed the idea of having JWS key distribution based on reference (URIs in the meta-data statement) only. That is much easier on the side of the entity and ors involved, keeping much of the simplicity of OIDC. The protocol draft will require that then the federation operator (FO) signs the key again at its source URL -- and the practical solution we could use for that is that the org publishes its public key, and the FO frequently checks whether a new key is avaialvle (from a URL pre-registered with the FO) and as it changes immediately re-signs it and publishes the signed key on the FO URI location. Easily automatable at the FO side using crond and Last-Modified HTTP headers, and - if you want it quicker than once a minute - you can even add a trigger URL service to it. Practical, simple and keeps complexity away from clients. And trivial to implement :) Opinions on this one welcome as well. Cheers, DavidG. -- David Groep ** Nikhef, Dutch National Institute for Subatomic Physics, PDP/ACR group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL ** ** New PGP key: 0x308E076A FP: 2facebea12803ba145685a21d80134c2308e076a **

1 0

IGTF OIDCfed scope and objectives discussion
by David Groep 16 Oct '17

16 Oct '17

Hi all, Since apparently this group is attracting a lot of interest in the wider world, I think it's good to actually write down our objectives and scope, if only to clarify that we are *not* intending to set up an alternative OIDC Fed next to eduGAIN or so :) The discussion at the All Hands meeting was clearer on that issue, but it's not written down anywhere. And that starts creating confusion ... Should we have a stab now at the scoping statement to identify objectives? Comments welcome, please! " The IGTF OIDC Fed effort focuses (primarily) on the establishment of trust between OIDC SPs in the Research and e-Infrastructures, where a common trust basis exists between them and between them and any of their 'upstream' or internal SPs, and where a common trust anchor or set of trust anchors would help alleviate the need to establish bi-lateral trust between all OIDC SPs and the collection of Infrastructure SP-IdP proxies (acting as OPs), and between SPs and (bridging) OPs of different Infrastructures when they inter-operate. In this respect, it is complementary to other OIDC Fed efforts in the general R&E space (in particular, we are not intending to mass-onboard OPs). The trust basis for the federation can be organised around the Snctfi framework, using common baselines where applicable (e.g. those developed as part of the Policy Development Kits in AARC and the CTSC). Incidental OPs that connect to the Federation can be assessed based on the IGTF AuthN Assurance Profiles. Trust establishment leverages the membership and assessment guidelines common to the IGTF. " I've added it tentatively to <http://wiki.eugridpma.org/Main/OIDCFed>, so the IGTF members can edit it directly, but let's discuss on the list :) Similarly, we should start actively reaching out to some of the implementors of the Infrastructure (proxy) operators (Nicolas, Mikael, Jens, Hannah, Brian, &c) to get the needs and requirements clear. I can think of several things here - there are ikely more: - is a technical bridge (single signing key) better? Or a distribution and a 'policy bridge' like we have today? - scoping and how to deal with proxies changing (or not changing!) scope and how we can facilitate such trust? - technical details? - time line? Let's make this a slightly livelier list :) Cheers, DavidG. -- David Groep ** Nikhef, Dutch National Institute for Subatomic Physics, PDP/ACR group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL ** ** New PGP key: 0x308E076A FP: 2facebea12803ba145685a21d80134c2308e076a **

4 5

Welcome to the IGTF OIDC Federation Task Force
by David Groep 04 Oct '17

04 Oct '17

Dear all, Thanks again for volunteering to join the IGTF OIDC Fedeeation Task Force. To facilitate communications (and to maybe allow a few non-IGTF folk to participate more easily at a later stage without getting the overhead of the IGTF-general mailing list), I've set up a dedicated list for this one: "IGTF OIDC Federation Task Force" <oidcfed(a)igtf.net> >From the notes of last week: "The IGTF DECIDES to set up a task force to push OIDC Federation next to its current trust anchor distribution. This group will - identify objectives - scope the needs and requirements - verify compatibility of the AP policy framework for technology- agnosticity with OpenID providers - test the scenario with the WLCG use case (what to distribute, involving Brian Bockelman as well) - assess the structure and needed meta-data in the trust anchor distribution, how to address RPDNC, and how it links with dynamic client registration through .well-known (with caching) - liaise with other OIDC Fed efforts and Roland Hedberg The size of the IGTF OIDC federation would again be O(100) organisations (but maybe more dynamic services), and not 10k+ - we expect to address the research and collaboration use case, not solve the general R&E fed problem here :) Limiting it to a enumarble set of organsiations will be implicit through the need to adhere to the IGTF baseline assurances, the membership process and review model, and maybe some coertion towards collabroation for projects in the same space. This worked well for keeping the number of authN providers reasonable over the last 15 years. The working group will be open, and initially consist of: JimB, Jens, DavidG, DaveK, Derek, Eric Yen, and Sang-Un. " Thus, you all have been subscribed to this list. We should start planning shortly on how to make some concrete progress beyond just mailman ;) Cheers, DavidG. -- David Groep ** Nikhef, Dutch National Institute for Subatomic Physics, PDP/ACR group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL ** ** New PGP key: 0x308E076A FP: 2facebea12803ba145685a21d80134c2308e076a **

1 1

2024

2023

2022

2021

2020

2019

2018

2017

igtf-oidcfed October 2017