AMDG Attribute Requirements

AMDG Attribute Requirements

Government

From Fed Canada (1st July 2011):

  • More than one protocol choice

  • How to co-exist with attribute authorities that do not have a common credential authority

  • The concept of an “attribute package”

    • E.g. a group of attributes without an explicit unique identifier

    • The processes to “validate” such a package at an authority without an authentication

  • The flavours of an attribute:

    • Unique: globally/locally (i.e. identifier)

    • Original id proofing process

    • Time since verified (& process)

    • Time last changed (& process)

    • Generated from other attributes

  • The role of consent and the types of consent processes required and the effect on the protocols

From eGov F2F meeting in Berlin, April 2011:

  • Develop a common approach to protocol choice, implementation and subsequent deployment

  • Schema

  • Semantics (there are generic and industry-specific attribute code lists everywhere (LDAP, x500, OASIS CIQ, Health's HL7, InCommon etc) so let’s not re-invent anything..rather re-use something/s*****) and from this develop

  • Metadata definition, and

  • Level of Assurance criteria for attributes

Beyond this I could envisage profiles being developed ( a la SAML) which bring together protocol-specific request and response messages, bound to transport mechanisms. But I think this is more the Purview of OASIS, IETF and such SDOs than us…

From NZ gov.

  • a common 'identifier' system to identify sending and receiving organisations, units or services within organisations, and identities (be they people or devices) within those organisations. What system do you have/know of that we could potentially re-use, e.g NewZealand.Government.DeptInternalAffairs.BirthsDeathsMarriages.XXX.XXX or urn:nzl.govt.dia.processes.credentialling:1-0)

From NIST

From DHS

Federal Emergency Response Officials (F/ERO) Emergency Support Functions and Critical Infrastructure and Key Resources

From the eGov mailing list:

  • attribute type: Friendly name ..sub type: verified, unverified

  • pseudonymous name ?? ..not everyone convinced..

  • attribute type: source ..sub type: authoritative, trusted, ##anyother


Higher Education & Research

Science Virtual Organizations (VO)

  • attributes should have metadata associated with them that gives info on

    • where the attribute came from (signed? something that says, as the VO aggregates information from a variety of sources about an individual, where each bit of information came from)

    • level of assurance for the information (different than the LoA for the authN)

  • attributes should have a common structure or definition

    • would be nice to be able to expect "employee" or "faculty" to mean the same thing, or link to some common definition for that region, so a VO knows the priority and detail of what it's getting