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