Present

Notes

To recap: we are looking to put the information in an entity attribute, either as a pointer to a profile or specify the rules themselves in a blob (the content and how encoded are still To Be Determined).

Björn asked about the readiness of the development team. Can SeamlessAccess implement what we specify? Does that make a difference to what we specify? Zacharias going to ask before the next meeting.

Pål skeptical. Defining a profile is just another way of doing the work twice, or that we never get round to doing the second part.

If InCommon have a need to implement the entity selection quickly, then there is scope for a profile communicated through a bilateral entity attribute.

If the profile is a pointer, that profile must be maintained by the metadata consumer so it's as available as the metadata consumer.

Further discussion about having a separate metadata distribution network for this selection metadata. We are not underestimating the effort required to build such a system.

Discussion then turned to the selection protocol itself

  • naming specific entities to select - we want to keep that
  • can we do "this kind but not these"?
  • want to build rules that are very specific (each criteria is combined using AND) and create a union of those specific rule (with OR)

Action on Alex: start a google doc so that we can communally work on a specification

Agreed that Alex to add a link to the exisiting google doc to wiki page (this is a link to the original trustinfo specification)

  • No labels

1 Comment

  1. SeamlessAccess development team ready to receive. We've looked over the requirements for this to be met (based on the requirements posed through InCommon), and they do not require much job and would not get in the way of other priorities for the software.