The next meeting is on Thursday 2 May
Present
Minutes
Pål's concerns
- can't put too much in metadata
- can't be live resolved, needs to be cached (we think this has been addressed by now)
- From REFEDS standards point of view, we want to have something that easily can be put into service
Original filtering language was JSON, then ported to XML but then we had the schema problems, so back to JSON. https://github.com/TheIdentitySelector/thiss-mdq/blob/eperez-trustinfo-schema/trustinfo.schema.json. Action: We could ask SeamlessAccess to provide a schema validation service
SImplest case is to have SeamlessAccess define some profiles and have the some way of signalling which profile a SP wants. However, this is application specific & not scalable. Our work has to be general enough so that it's not locked into SeamlessAccess.
What do the federations in the room want?
- SWAMID: would like to define 2 profiles: SWAMID only, SWAMID + eduGAIN
- InCommon: want to define a list of IdPs, or use the whole trustinfo filtering language. Has time sensitivity because wanting to implemetn SeamlessAccess as default discovery service for federation.
- UK federation: no use cases
What are the actors?
- Metadata producers: A federation operator adds the metadata. Depending on the type of metadata management tooling, the fedop could allow any metadata to be added, or could define some standard blobs and allow federation participants to select blobs in a metadata management tool (these are profiles too!)
- Metadata distribution systems
- Metadata consumer then needs to a) recognise and b) decode the blob
We discussed whether this was in REFEDS remit. Would want more than one use case:
- SeamlessAccess
- thiss.io run on your own
- only higher education institutions
REFEDS would want one Entity Attribute and a standardised language, rather than an entity attribute per application. Also need to consider SAML / OIDC
Is this a selection language? We recognised that "trust info" is an overloaded term (could be easily mistaken for technical trust, as in interoperate because has metadata about the other entity). We explored alternatives and converged on "entity selection protocol". It is like a metadata-safe version of XPath or prepared SQL statements: we define some parameters that can be used to select entities.
The proposed XML schema has
<enumeration value="registrationAuthority"/>
<enumeration value="entity_category"/>
<enumeration value="assurance_certification"/>
<enumeration value="entity_category_support"/>
<enumeration value="md_source"/>
Are these sufficient?