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.
Hi David,
I think what you have here is a good start.
I wish we could nix the term 'OIDC SP' as I feel that the Service Provider term (however accurate) is rather overloaded... is this what you are calling an 'OP' or is that something different?
It would be helpful to me if we could develop a small set of diagrams/illustrations to help keep definitions clear, and to help us communicate to (me and) others what all the parts and gaps are that we hope to address.
- Derek
On Oct 15, 2017, at 12:26 PM, David Groep davidg@nikhef.nl wrote:
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 **
--- Derek Simmel Pittsburgh Supercomputing Center dsimmel@psc.edu +1 (412) 268-1035
Hi Derek,
On 2017-10-15 18:52, Derek Simmel wrote:
I wish we could nix the term 'OIDC SP' as I feel that the Service Provider term (however accurate) is rather overloaded... is this what you are calling an 'OP' or is that something different?
Quite true, my bad. Agree we should use the terminology consistently, so I propose we stick to RP (the OIDC "SP" term) and the OIDC Provider ('OP') terminology. I've updated the Wiki to reflect that. Not I hope I'm not horribly mistaken here ;)
It would be helpful to me if we could develop a small set of diagrams/illustrations to help keep definitions clear, and to help us communicate to (me and) others what all the parts and gaps are that we hope to address.
If we indeed align fully with the OIDC terminology, the standard graphs should work as well for basic interactions. For the federation bit, we will need some graphs :)
Cheers, DavidG.
- Derek
On Oct 15, 2017, at 12:26 PM, David Groep davidg@nikhef.nl wrote:
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 **
--- Derek Simmel Pittsburgh Supercomputing Center dsimmel@psc.edu +1 (412) 268-1035
Hi all,
In case you’re at I2 TechEx this week I’m happy to continue the discussion in person. I’m up for an ACAMP session about it on Wednesday.
I’m not convinced there’s work for us to do related to RPDNC (Relying Party Defined Namespace Constraints). I think the OIDC spec already gives us unique namespaces, based on ownership of the issuer URL. It’s one of many examples of OIDC learning from the mistakes of the past. http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability says:
“The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.”
Lastly, to help make this a livelier list, I’ll disagree with DavidG and state that I think IGTF *should* set up an alternative OIDC Fed next to eduGAIN. With all due respect to the OIDC Fed discussions happening in eduGAIN/REFEDS, I prefer not to apply all the heavy-weight eduGAIN/REFEDS methodology to OIDC. I think IGTF has a lighter-weight methodology that results in a higher level of trust because it’s focused on supporting e-research.
I’d like this task force to work towards a simple trust anchor distribution that includes https://cilogon.org/.well-known/openid-configuration as an OP that operates under IGTF policies/standards. I’m wondering if I need to produce a CP/CPS-equivalent document for the CILogon OP, borrowing liberally from the current CILogon CP/CPS documents, that demonstrates compliance with Snctfi.
Regards, Jim
Hi Jim,
15 okt. 2017 kl. 15:40 skrev Basney, Jim jbasney@illinois.edu:
In case you’re at I2 TechEx this week I’m happy to continue the discussion in person. I’m up for an ACAMP session about it on Wednesday.
Me too.
I’m not convinced there’s work for us to do related to RPDNC (Relying Party Defined Namespace Constraints). I think the OIDC spec already gives us unique namespaces, based on ownership of the issuer URL. It’s one of many examples of OIDC learning from the mistakes of the past. http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability says:
“The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.”
Lastly, to help make this a livelier list, I’ll disagree with DavidG and state that I think IGTF *should* set up an alternative OIDC Fed next to eduGAIN. With all due respect to the OIDC Fed discussions happening in eduGAIN/REFEDS, I prefer not to apply all the heavy-weight eduGAIN/REFEDS methodology to OIDC.
I’d like to know what’s too heavy-weight in the OIDC fed draft.
Writing the draft I hoped to make it possible to organize federations any which way one wanted. There might well be an OIDC federation which has the same set of members as EduGAIN, but that was not on my agenda writing the draft.
I think IGTF has a lighter-weight methodology that results in a higher level of trust because it’s focused on supporting e-research.
A discussion item for Wednesday then.
I’d like this task force to work towards a simple trust anchor distribution that includes https://cilogon.org/.well-known/openid-configuration as an OP that operates under IGTF policies/standards. I’m wondering if I need to produce a CP/CPS-equivalent document for the CILogon OP, borrowing liberally from the current CILogon CP/CPS documents, that demonstrates compliance with Snctfi.
Regards, Jim
Hi Jim, all,
On 2017-10-16 00:40, Basney, Jim wrote:
In case you’re at I2 TechEx this week I’m happy to continue the discussion in person. I’m up for an ACAMP session about it on Wednesday.
Yes, we should propose it and make sure it happens on Wed (if we want e.g. Hannah to attend as well). Let's make that happen.
I’m not convinced there’s work for us to do related to RPDNC (Relying Party Defined Namespace Constraints). I think the OIDC spec already gives us unique namespaces, based on ownership of the issuer URL. It’s one of many examples of OIDC learning from the mistakes of the past. http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability says:
“The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.”
True, although we now give some additional guidance to our RPs on what parts of the subject name space of any authority falls within the assurance compliance claims of the IGTF (we use that for some commercial PKIX CAs at the moment). Indeed the better way here would be to re-use the 'additional' OIDC claims of the type "eduperson_assurance" such as Niels has proposed in OIDCre in https://github.com/surfnet-niels/refeds-oidcre-saml-oidc-mapping/blob/master... and that should take care of most of the RPDNC use cases when used together with the standard OIDC spec.
Lastly, to help make this a livelier list, I’ll disagree with DavidG and state that I think IGTF *should* set up an alternative OIDC Fed next to eduGAIN. With all due respect to the OIDC Fed discussions happening in eduGAIN/REFEDS, I prefer not to apply all the heavy-weight eduGAIN/REFEDS methodology to OIDC. I think IGTF has a lighter-weight methodology that results in a higher level of trust because it’s focused on supporting e-research.
We might actually be in some form of agreement: what I meant was that we (the IGTF) do not have the ambition to become the 'uber-OIDC fed' that addresses the *general* use case of connecting any academic OP to any useful RP out there. We will probably live in a inter-federation world again, and in that space I think the IGTF should focus on, indeed, the RPs and (selected) OPs that are specifically useful for research and e-Infrastructures. We can then confederate with the others on a global level just once, I hope? That's a discussion (how and when and if) that we should have, e.g. at the ACAMP.
And re-using the existing IGTF processes (both policy and operations-wise) I think will indeed allow for quicker solutions and deployments.
I’d like this task force to work towards a simple trust anchor distribution that includes https://cilogon.org/.well-known/openid-configuration as an OP that operates under IGTF policies/standards. I’m wondering if I need to produce a CP/CPS-equivalent document for the CILogon OP, borrowing liberally from the current CILogon CP/CPS documents, that demonstrates compliance with Snctfi.
I like trust anchor distributions ("policy bridges") :) And making one is not all that complex, unless your federation becomes really large. And I still expect O(100) entities that need a trust anchor, not 100k+. For the OPs, I think we should be re-using the existing assurance profiles (so for CILogon that would be BIRCH and DOGWOOD). It's for the RPs that I think Snctfi has a great role to play to inspire trust in them.
So - to first order - I would think that cilogon.org as an OP should NOT have to draft new assurance policies, just a different technology profile.
Let's start trashing things out during ACAMP ;)
Cheers, DavidG.
Regards, Jim
-
Basney, Jim -
David Groep -
Derek Simmel -
Roland Hedberg