Attribute Management (2G2)

Attribute Management (2G2)

Convener: Sal

Notes-taker(s): Sal

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Attributes arrange themselves by longevity and frequency of change: identifiers, authorizations, lifecycle management of the attribute for use, e,g,

at the bottom (id) name, date of birth, standardization of "basic" attributes would be a boon to interoperability and subsequent usage is still lacking

are there situations where there are multiple authoritative and trusted sources for a given attribute -

mapping/difference between trusted and authoritative source

trusted, authoritative, reliability of attributes matter – I is this a job of the IDP or the attribute provider. -

Provisioning a Google account. Who's the trusted attribute store. -

Control of attributes: base, and dynamic for example location based attributes, and will users ever fulfill this role. -

Base attributes established w/o an authoritative source since government is not in the game at this point, though some (VA, Canada are considering it. -

Can you ever get normalization of attributes?. Who might do this? Kantara draft on the findings of this question. -

Are there buckets of attributes that we can all agree on to assist in interop. For example, "street identity"

Kantara looking at healthcare, egov, first responder, telco federated id (AAA ID?) The use cases matter. There will never be agreement on attribute definitions in the large.

Rise of the attribute exchange to ease identity friction between providers. Evolution of the attribute hub.

Government entities are authoritative but hands are tied due to legal restrictions. But what if a citizen consented a la UMA.

How do you get citizens to buy into this and protect their privacy? How to add policy to usage - store, sell, and access.

User control is great - need to ensure implementors observe the controls.

Federated identity, reduces the attack surface but complicates the transaction.

Need for restful, simplified access to attribute stores.

Graph = attribute. crawlers, RDF

Attributes used to step-up authentication. Use cases for this? The case for an Experian, Lexis/Nexis,

Distinguish using the data vs storing it. Levels of assurance. The level of assurance in a transaction can never be higher than at the time of registration? Using multiple- factors can further validate the authentication but cannot quantify its reliability as authN as those arent secrets - others know them. 800-63 credentialing is very different than knowledge based.

Trust elevation applicable to both the user and the user's attributes. Attribute assurance. LOA on assurance via OIX ends with a score.

Lacking of Gov't standards around authorization.

Big and little gov't interested in participating. Virginia DMV a leader? NAPHSIS birthdate of record. Already have rules in place for treatment of their info. There needs to be a public PR campaign of sorts that take the evil out of the AX from the Government.

"Nobody asks for your Google card, but they do ask for your driver license."