Richard,
As per discussions which have been
occurring in the Attribute Management Discussion Group (AMDG) during the
development of their report to make recommendations on where focused effort
from the Kantara Initiative might help move this space [attribute management]
forward I am requesting, during the revision of the SAC, that the IAF glossary
also be revisited.
While the AMDG is primarily focussed on
attributes I would suggest that all definitions in the glossary be reviewed for
alignment with ITU X.1252. The AMDG would like to recommend the following
definitions
* Attribute - Information bound to a
subject that specifies a characteristic of the subject. In other words, a
property associated with an individual.
* Identity - A representation of a subject
in the form of one or more attributes that allow the subject or subjects to be
sufficiently distinguished within context. For identity management (IdM)
purposes, the term identity is understood as contextual identity (subset of
attributes), i.e., the variety of attributes is limited by a framework with
defined boundary conditions (the context) in which the entity exists and
interacts.
* Identification - The process of
recognizing a subject by contextual characteristics. In other words, the
process of using claimed or observed attributes of an individual to infer who
the individual is.
* Identity Proofing - A process which
validates and verifies sufficient information to confirm the claimed identity
of the subject. In other words, the process by which identity related
information is validated so as to identify an individual with a degree of
uniqueness and certitude sufficient for the purposes for which that identity is
to be used.
To the already existing definitions the
AMDG would like to recommend the addition of the following terms to the
Glossary:
* Identity Attribute - Information bound
to a subject identity that specifies a characteristic of the subject.
* Identity Context - the environment or
circumstances in which identity information is communicated and perceived.
Individuals operate in multiple identity contexts (e.g., legal, social,
employment, business, pseudononymous) and may identify themselves differently
based on the context.
* Authoritative Party - An organization or
individual that is trusted to be an authority on the identity related
attributes or roles associated with users and subjects of services.
Ken
Kenneth Dagg
Senior Project Co-ordinator | Coordonnateur de projet supérieur
Security and Identity Management | Sécurité et gestion des identités
Chief Information Officer Branch | Direction du dirigeant principal de
l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du
Canada
Ottawa, Canada K1A 0R5
Kenneth.Dagg@tbs-sct.gc.ca
Telephone | Téléphone
613-957-7041 / Facsimile | Télécopieur 613-954-6642 / Teletypewriter |
Téléimprimeur 613-957-9090
Government of Canada | Gouvernement du Canada
From:
dg-am-bounces@kantarainitiative.org
[mailto:dg-am-bounces@kantarainitiative.org] On
Behalf Of David L. Wasley
Sent: March 22, 2012 9:26 PM
To:
Cc:
Subject: Re: [DG-AM] definition of
Identity Attribute for the report
No - I don't believe KI should be bound to 800-63 regarding
attributes WRT this report. 800-63 is almost entirely about
credentials, not attributes. To the extent it want's attributes embedded
in credentials (e.g. PKI) or available from CSPs in an assertion, that can be
accommodated as a subset of the more general attribute set.
In our experience with Federal apps, they do want a "name"
but only to use as a salutation, not for access control. For access, we
typically provide an opaque identifier, ideally one that is targeted
specifically to the particular app.
The hard part about attributes in general is defining the syntax and
semantics (or dictionary and grammar) and what LOA means.
David
On Mar 22, 2012, at 4:12 PM,
+1
What Dave is implying, and Abbie is supporting (as am
I on a personal basis but not necessarily the view of my employer) is that the
KI definition is bound to 800-63 which is, err, outdated.
If the AM DG Report was to be bound to the IAF in
some way (like for example, the Privacy Assessment Criteria from
But I’m not sure there is a strong reason why the AM
DG Report should be bound to the IAF KI one, but happy to be corrected if I’m
wrong.
Cheers
Colin
From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On
Behalf Of Barbir,
Abbie
Sent: Friday, 23 March 2012 8:34 a.m.
To: David L. Wasley; dg-am@kantarainitiative.org
Subject: Re: [DG-AM] definition of Identity
Attribute for the report
Hi
Agree and as such
the itu definition is better suited since identity is defined as a collection
of attributes
We really need to
standardize on the use of international definitions since ISO 29915 builds on
x.1252
cheers
From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On
Behalf Of David L.
Wasley
Sent: Thursday, March 22, 2012 3:02 PM
To: dg-am@kantarainitiative.org
Subject: Re: [DG-AM] definition of Identity
Attribute for the report
Some background and a different perspective.
The original IAF was developed from the original NIST
800-63. The notion of "identity" in 800-63 was basically
"a name and something added to make it unique" which is where the
definition Ken found came from. The world has moved quite far from that
(naive) notion.
In the identity federation with which I am most
familiar (InCommon), we consider "identity attributes" to be
potentially "anything that is true about a given entity."
Identifiers, facts, preferences, etc. For example,
"student" is an important attribute that supports access to services
and resources restricted to "students." The basic set of
attributes we use is defined in the eduPerson Object Class (http://middleware.internet2.edu/eduperson/).
Another set of attributes that we have discussed but
not implemented would provide information that can help a RP/SP display
information to a user, for example "visually impaired" -->>
"increase font size," or "color blind" or "deaf",
etc.
In this broader notion of "attribute" there
are many different kinds:
- some things are unique to the particular
entity; others are shared with other entities
- some are assigned by an SOA, e.g., passport
number; others are self selected, e.g., nickname or display name.
- some are transient, e.g., "student";
others are permanent and/or never reassigned, e.g., some identifiers.
- the degree of authoritativeness of any
attribute is determined by how it is acquired by the ISP and how current it is,
etc.
- not all attributes will be available from any
one ISP, certainly not with the same degree of assurance
- etc.
We encourage RP/SPs to request the minimum set of
attributes that they need in order make an access decision.
David
On Mar 22, 2012, at 10:47 AM,
Thanks Ken,
OK so if we move
away from ITU f, toward "Identity
Attribute is information that contributes to establishing the identity (a
unique name) of a single person?"
Yes attributes can
support a “higher level of authN” but also are related to authZ independent of
or in combination with name or identifier. It depends on the
attribute types, so might we expand this to include “.. contributes to
establishing the identity (unique name) and “permissions/privileges/claims” of
an individual”
Not sure what the
actual word is there and put these 3 in as example/suggestion.
From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On
Behalf Of
Sent: Thursday, March 22, 2012 12:56 PM
To: dg-am@kantarainitiative.org
Subject: [DG-AM] definition of Identity
Attribute for the report
I checked for the term
Identity Attribute in the IAF Glossary and did not find it. As such, I
did not send a note to the IAWG.
However, the following terms
are in the glossary:
* Attribute - a property
associated with an individual
* Identity - a unique name
for a single person. Because a person’s legal name is not necessarily unique,
identity must include enough additional information (for example, an address or
some unique identifier such as an employee or account number) to make a unique
name.
* Identification - Process
of using claimed or observed attributes of an individual to infer who the
individual is.
* Identity Proofing - The
process by which identity related information is validated so as to identify a
person with a degree of uniqueness and certitude sufficient for the purposes
for which that identity is to be used.
The AMDG report currently
defines Identity Attribute as Information bound to a subject identity that
specifies a characteristic of the subject.
I suggest that this
definition is not in alignment with the definitions contained in the IAF
glossary. While I have nothing against the definitions contained in ITU-T
X.1252 I would suggest that we remain consistent and aligned with KI
definitions. I believe the following would be more aligned, "Identity
Attribute is information that contributes to establishing the identity (a
unique name) of a single person?"
Comments? Or reasons not to
use this definition (other than it’s not the ITU definition)?
BTW: I have updated the
report. I added a glossary and some text about RP requirements. I also
took the opportunity to align the recommendations at the start of the report
with the recommendations at the end.
Ken
Kenneth Dagg
Senior Project Co-ordinator | Coordonnateur de projet supérieur
Security and Identity Management | Sécurité et gestion des identités
Chief Information Officer Branch | Direction du dirigeant principal de
l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du
Kenneth.Dagg@tbs-sct.gc.ca
Telephone | Téléphone 613-957-7041 / Facsimile |
Télécopieur 613-954-6642 / Teletypewriter | Téléimprimeur 613-957-9090
Government of
_______________________________________________
DG-AM mailing list
DG-AM@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-am
This message w/attachments (message) is intended
solely for the use of the intended recipient(s) and may contain information
that is privileged, confidential or proprietary. If you are not an intended
recipient, please notify the sender, and then please delete and destroy all
copies and attachments, and be advised that any review or dissemination of, or
the taking of any action in reliance on, the information contained in or
attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a
solicitation of any investment products or other financial product or service,
an official confirmation of any transaction, or an official statement of
Sender. Subject to applicable law, Sender may intercept, monitor, review and
retain e-communications (EC) traveling through its networks/systems and may
produce any such EC to regulators, law enforcement, in litigation and as
required by law.
The laws of the country of each sender/recipient may impact the handling of EC,
and EC may be archived, supervised and produced in countries other than the
country in which you are located. This message cannot be guaranteed to be
secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of
America Corporation. Securities and Insurance Products: * Are Not FDIC Insured
* Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal
Government Agency. Attachments that are part of this EC may have additional
important disclosures and disclaimers, which you should read. This message is
subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer.
By messaging with Sender you consent to the foregoing.
====
CAUTION: This email message and any attachments contain information that
may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended
recipient, any use, disclosure or copying of this message or attachments is
strictly prohibited. If you have received this email message in error please
notify us immediately and erase all copies of the message and attachments.
Thank you.
==== _______________________________________________
DG-AM mailing list
DG-AM@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-am