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

• A Credential Reliability and Revocation Model for Federated Identities

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