Room 8: 2:00 – 3:00
Attribute Assurance
SAML2INT says you can only have one assertion. Would this need to be changed if we use attribute authorities?
Problem at the moment is that we do not have a well-defined idea as to how attribute authorities would work in the federation workflow. A simple way to address this is to ensure that any IdP would only interact with an AA of the same assurance level.
Some relationship to guest IdP and assurance level for attributes released via guest IdPs.
Is some of this people being too reliant on attributes to do group management? i.e. trying to shift the group work from one place to another.
Risk management is an issue here – institutions don’t have effective tools for managing this.
REFEDS are looking at baseline assurance across federations with a focus on federation operator practices.
How do we match up: Kantara = SWAMID LOA1 = InCommon Bronze? Who makes these decisions?
Leif’s proposal for an IANA registry: http://tools.ietf.org/html/rfc6711.
Common experience of people saying ‘I NEED LOA2’ without understanding what that means. Often when you unpack it this could be offered by current infrastructure if we had better ways of expressing our current practices and look at ways of provisioning areas of concern via more lightweight assurance profiles or entity categories. i.e. all our IdP’s with this flag have DNA checked their students (joke example).
Need: a credible set of people who can work as a committee to make value judgements about what matters in this area. Is this Kantara? Is this REFEDS? Do we want REFEDS to be this sort of a thing?
Need: to build towards a REFEDS profile under Kantara?
Need: credible use cases of people who really need specific levels of assurance.