Attributes Claims - Identify Attributes LOA
Issue/Topic: Attributes Claims – Identify Attributes LOA (T2G)
Conference: IIW-East September 9-10, 2010 in Washington DC Complete Set of Notes
Convener: David Wasley
Notes-taker(s): Heather West
Tags for the session - technology discussed/ideas considered:
LOA, attribute, interoperability, credential exchange, federation
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Levels of assurance are largely applied to identifiers or individual credentials/transactions, but do not translate well to a more complicated vision of identity within context.
Is identity LOA distinct from credential LOA? Should attributes have an LOA? Is there a difference between aggregated data or aquired data from a source of authority?
Is identity the complete picture? Knowing everything about a person at all times?
Is LOA even the right terminology for attributes? Maybe it’s LOA that the attribute is coming from a trusted source?
There are three axes based on strenght of each: credential bound to a specific individual, greater privacy, attribute assurance. Where should certain kinds of transactions fall? What kinds of levels should be necessary for permissions?
A number of example setups were discussed. Credential LOA is mostyly about tech – what does id proofing add? What part of that is meaningful to an RP?
STORK defines identity – in the levels of assurance. Does 800.63 – only covers the identity elements, not much about proofing otuside preventing fraud. The bottom line for attributes is what the IdP knows and how well they know it.
Aggreation of data or a source of authority? How do you ensure that IdPs trust SOAs? Certification?
Do we expect RPs to chase down each attribute? It doesn’t scale to connect the data provenince and expect everyone to care. You can pass around that signed object, or you can ask everyone to go retrieve it each time.
How can you represent LOA for identity – metric for assertion as a whole? Groups of attrbutes? Weakest assertion? Per-attribute?
TFP doesn’t deal with attributes, on purpose. Always been RP’s problem, but this is inhibiting the big bang we’re looking for.
Data quality is the real challenge in the real world.
Access management decisions aren’t made with real names – it’s abstract identifiers, personalization decisions, life history, eligibility attributes... Attribute TF is different than an assurance TF. We don’t have a great set of terms for this.
