Review of Notes from the last meeting: 

Quick review of the place we got to last time. 

We do want to do the equivalent of entity categories in metadata for OIDFed, but is this really possible in the current structure of OIDFed? Niels is thinking around some ideas here and is thinking about this for the wallet ecosystem.  How do we do this is the current model? This is currently via claims.

Quick overview of the trust model: 

In the OIDFed world we have a full hieracrchical trust model going from the federation to the entity. When we move to interfederation we effectively add a "superior trust anchor" on top but maintain the current trust model. Trust model of the federation is acting as an intermediary, with eduGAIN as the superior trust anchor.  Currently in SAML, we effectively eliminate the intermediate and create a new aggregate (remove the signature of the federation and add the eduGAIN signature). When this comes back downstream the eduGAIN signature is removed and the federation republishes. In OIDFed the whole heirarchy is maintained. 

Other main difference is in OIDFed is that you don't sign metadata, you sign the KEYS. You are not technically supposed to distribute metadata. So what is the superior trust anchor doing? They are signing the key of the intermediates.  An intermediate CAN sign policies they are enforcing but they are very limited. 

What is the role of eduGAIN? Are we just saying that we are really sure that these keys belong to someone and not doing any organisational vetting.  This really depends on the registration policy of the federation and the statements that are being made. This is completely IMPLICIT through signing the keys / onboarding? Is there a direct correlation between signing the key and validating the metadata? What is that statement making? When you do the fetch of metadata, what is the trust anchor claiming? entityID+keypair. How do we know when a change is made?  If you want to manage changes in metadata, you would have to make a policy to say X cannot change. Is this something we want to achieve? 

Trustmark "eduGAIN member" = ? Needs to be regularly checked.  Trust marks can be both self-issued or issued from a Trust Anchor. These do need to be validated against a Trust Anchor. Caching can be a problem here.  

Is a federation membership trustmark is used, then it is only useful if all the federation trustmarks means the same. 

Would Surf maintain the proxy in an OIDFed model? Probably yes. 

Name management issues across federations remain the same. 

What fields should be set as unchangeable for any given piece of metadata? Need to agree on which elements need to be changed only by the federation. Fundamental thing to agree.  For example a contact can be changed, an organisation name cannot be changed?  The statement from the federation operator that the organisation is allowed to assert a specific name and when they change it they have that same agreement on 

Question: All the trust mark policy power is going to have to be encoded at the national federation resolver?

When we sign the metadata as eduGAIN, what statements are we making? We don't want a messy approach. 

It would be useful to write a statement saying what statement eduGAIN is making when it signs metadata for both SAML and OIDFed.

We care quite a lot about things that are currently in a non-enforced document - Metadata Registration Practice Statement. 

Looking at differences as to where information is held in metadata - e.g. OIDC vs OIDFed. 

Question: are we planning on only talking OIDC as a protocol? What about wallets?

Can we support entity types being different things (e.g. OP / RP / intermediate)

----------------------------------------

ACTION: eduGAIN OT / Secretariat to look at writing down a comparison of what is meant when eduGAIN signs X and a federation signs X across both SAML and OIDFed.