AMDG Attribute Requirements

Owned by Former user (Deleted)
Last updated: Oct 15, 2012 by Former user (Deleted)
2 min read

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