Present

Minutes

  • We have two tasks.Define the entity attribute, and define the payload.
  • Albert noted the time pressure to deploy for InCommon. They could define a bilateral entity attribute, but also possible to use something multilateral. InCommon might also use a versioned draft specification as an early proof of concept.
  • We discounted using a temporary name of the entity attribute while we are piloting. Once it's in metadata, it'll get stuck there forever
  • The working group has not been able to get any concrete use cases other than the IdP discovery use case. We have speculated about IdPs using filtering, we have speculated about proxies, we have called for use cases in the blog post and at a face-to-face REFEDS meeting. We noted that the use case of different deployments of SeamlessAccess/ thiss.io which use different filter rules is not a separate use case. We have therefore agreed to limit the scope to IdP discovery.
  • We had a discussion about the 2 ways of sending information to SeamlessAccess (metadata and button). We came to the conclusion that metadata is really the only scalable method and advanced integration is out of scope for REFEDS (and if SP trying to do this and metadata, it's up to them to understand the implications. ACTION: the specification will include note to say we do not say how our spec is composed with other ways of signalling filtering
  • We will specify a single-valued entity attribute which is targetted to the IdP discovery use case because that will be easier
    • to code XPath for XML representation
    • explain to users
  • We discussed moving to a generic case. Would we need to have some way of specifying the consumer / use case? Or multiple entity attributes, one for each use case. We agreed to have only a single consultation so that we don't confuse people / not get their attention. ACTION: when we consult, we should specifically ask if we are going about this the right way

Next meeting: 12 September


  • No labels