...
Minutes
Getting up to speed
- Albert reported on a chat on SeamlessAccess Slack about how SeamlessAccess processes trustinfo metadata.
- Björn: XML encoded Base64, implemented in pyFF which creates a JSON discovery file, shipped to service (JSON MDQ server). Then either magic button on javascript on service page queries info about entities. Now looking to implement JSON version of trustinfo.
- Albert: What this WG working on ... advice is that trustinfo JSON blob. Enrique mentioned global profile in
EntitiesDescriptor - Björn: yes, we have talked about global profile
- Pål: where is profile defined?
- Björn: only person who knows md_source is discovery service, so can publish all global profile
- So who creates this? SeamlessAccess! fedop then adds the profile name
- But SeamlessAccess needs more fine-grained filters (individual Idps in or out) and other customisation. Therefore we need to look how to combine global profiles with these fine grained rules.
Profiles
We have talked defining profiles for SPs to use. In fact, the demo page at https://deploy-preview-275--thiss.netlify.app/ implements profile (listed here) for use in the button.
Benefits:
- keep metadata size low because the entity attribute will contain only a URI to the profile, not the full blob
- cleaner metadata
- some uses cases are very easy to sovle with this (for example, only showing IdPs which are part of a specific Consortium)
- some parts of the original trustinfo spec are specific to the metadata consumer (md_source is the clearest example) and profiles make this completely transparent to the SP
Disadvantages
- Hard to implement fine-grained control through profiles (such as explicitly adding or removing individual IdPs; or an entity list which changes relatively often, such as an SP which Several concrete use cases: SP only lists IdPs that it's done pre-integration checks ; only Idps which are part of specific consortium.
- pass by reference: smaller size of metadata; cleaner metadata.
- Can we make it that profile is defined at SeamlessAccess? Log in, submit the trustinfo.
- Same EA for other? As long as consumer can determine which type it is.
- ZT: hundreds of SPs using S/A so login and how SP informs S/A is crucial to determine
- profile name in button, button controlled by InCommon
- Albert: two feet in 3 different boats
- Pål: can we adapt what SeamlessAccess has done .and standardise?
- trustinfo in EntitiesDescriptor? We have many ways to do this:
- in aggregates, eduGAIN as a proxy, S/A defines these profiles
- scaling: got to be through entity attribute so filter by reference can't solve everything (scalability, fine-grained)
- with). Need to have many profiles, or to define combination rules.
We always come back to the question: how does one define the profiles? At the metadata consuming site? But as there are hundreds of SPs using SeamlessAccess, the mechanism that allows the SP to inform SeamlessAccess is crucial to determine. If SPs need to login to upload their profile, there's another authn/authz system that needs to be developed. Therefore we concluded that for the mechanism to scale, it has to be through the entity attribute.
Global profiles
Talked about defining profiles per-federation and including those in the EntitiesDescriptor of that federation's eduGAIN upstream. Yes, you can add an entity attribute to the EntitiesDescriptor. Would that get processed correctly by federation operators, eduGAIN intermediaries, the ultimate metadata consumer? And we wold still have to define combination rules for a global profile and fine-grained control.
Summary
- Agree that entity-selection-profile a good name ... not tied to IdPs ... but then you we need to get the logical combo defined
- Starting to get consensus towards 2-step standardisation process: the attribute and then the content and combination rules