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, Salvatore D'Agostino wrote:

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 Dagg, Kenneth 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 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

_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am

+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 P3 WG is bound to the IAF SACs and the Kantara and Federal Privacy Profiles) then outdated or not, we would need to align. 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, Salvatore D'Agostino wrote: 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.orgmailto:dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Thursday, March 22, 2012 12:56 PM To: dg-am@kantarainitiative.orgmailto: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 Canada Ottawa, Canada K1A 0R5 Kenneth.Dagg@tbs-sct.gc.camailto: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 [X] _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.orgmailto: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. ====

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, Colin Wallis wrote:

+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 P3 WG is bound to the IAF SACs and the Kantara and Federal Privacy Profiles) then outdated or not, we would need to align.

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, Salvatore D'Agostino wrote:

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 Dagg, Kenneth 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 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

_______________________________________________ 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

Thanks Ken for reaching out to the IAWG, and others for the discussion. I think this points out the very tricky nature of the definition. Our report is not really bound by anything other than best guidance. This conversation helped us to achieve that and while a consideration of an expansion on the 1252 definition may have some merit it is probably in the general discussion of the "use" of attributes as opposed to the "what is". Is consensus to stay with the existing ITU definition for the report? Regards, Sal -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Friday, March 23, 2012 9:04 AM To: 'David L. Wasley'; Colin Wallis Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report The discussion has been excellent. I will make a recommendation to the IAWG to update their glossary to reflect the discussion. 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 -----Original Message----- 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: Colin Wallis Cc: dg-am@kantarainitiative.org 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, Colin Wallis wrote: +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 P3 WG is bound to the IAF SACs and the Kantara and Federal Privacy Profiles) then outdated or not, we would need to align. 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, Salvatore D'Agostino wrote: 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 Dagg, Kenneth 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 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 rtfimage:// _______________________________________________ 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 _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am

+1  --Keith ________ On 03/23/12, "Dagg, Kenneth" wrote:

That was my understanding of the discussion.

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

-----Original Message----- From: Salvatore D'Agostino [mailto:sal@idmachines.com](javascript:main.compose() Sent: March 23, 2012 9:49 AM To: Dagg, Kenneth; 'David L. Wasley'; 'Colin Wallis' Cc: dg-am@kantarainitiative.org Subject: RE: [DG-AM] definition of Identity Attribute for the report

Thanks Ken for reaching out to the IAWG, and others for the discussion.

I think this points out the very tricky nature of the definition.

Our report is not really bound by anything other than best guidance. This conversation helped us to achieve that and while a consideration of an expansion on the 1252 definition may have some merit it is probably in the general discussion of the "use" of attributes as opposed to the "what is".

Is consensus to stay with the existing ITU definition for the report?

Regards,

Sal

-----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org](javascript:main.compose() On Behalf Of Dagg, Kenneth Sent: Friday, March 23, 2012 9:04 AM To: 'David L. Wasley'; Colin Wallis Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report

The discussion has been excellent. I will make a recommendation to the IAWG to update their glossary to reflect the discussion.

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

-----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org](javascript:main.compose() On Behalf Of David L. Wasley Sent: March 22, 2012 9:26 PM To: Colin Wallis Cc: dg-am@kantarainitiative.org 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, Colin Wallis wrote:

+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 P3 WG is bound to the IAF SACs and the Kantara and Federal Privacy Profiles) then outdated or not, we would need to align.

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](javascript:main.compose() 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](javascript:main.compose() 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, Salvatore D'Agostino wrote:

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](javascript:main.compose() On Behalf Of Dagg, Kenneth 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 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

rtfimage://

_______________________________________________ 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

_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am

_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am

Agree that there is a distinction between “core identity” attributes and others that are acquired. Is this in x.1254? Let’s see if and how we can include the distinction. From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Joanne Knight Sent: Monday, March 26, 2012 4:47 PM To: 'David L. Wasley'; dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report There are two point I would pick up here. 1) If we define Identity Attribute as the values needed to establish that an individual entity in unique then adding attributes such as Student would mean an unnecessary number of attributes would need to be collected to achieive uniqueness. 2) As per previous email, we have moved further to a point where we consider Role or Context separately from unique identity. For example in an Education system one unique identity may have more than one role e.g. Student and Teacher. The identity is the same for both but the role they perform in different situations changes. We would attach rights and permissions to the combination of identity and role (personna) not to the identity on its own. Identifiers, facts and preferences may also be different depending on the role. e.g. Joe Bloggs teaches Mathematics but is learning how to paint. In his personna of Mathematics teacher his qualifications and use of the title Professor are relevant, when he is learning to paint he no longer wishes to be referred to as Professor and his mathematic and teaching qualifications are also unlikely to be relevant to his learning or ability to paint. Don't we want to move to an environment where a person can establish their unique identity and attach it to a credential that allows them to reuse this identity when registering with any organisation. If we encumber that identity with role information that is only relevant to one organisation or system context then I would suggest we would be designing a global service centric data store rather than a person centric ecosystem. Just my thoughts From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of David L. Wasley Sent: Friday, 23 March 2012 8:02 a.m. 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, Salvatore D'Agostino wrote: 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 Dagg, Kenneth 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 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 rtfimage:// _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am ==== 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. ====

Thanks Colin, Have not seen 1254 just know it’s there, thanks. So that leaves plenty of room. About to run out of battery on plane, I will run through the draft and see if we can add clarifying language. Regards, Sal From: Colin Wallis [mailto:Colin.Wallis@dia.govt.nz] Sent: Monday, March 26, 2012 7:24 PM To: 'Salvatore D'Agostino'; Joanne Knight; 'David L. Wasley'; dg-am@kantarainitiative.org Subject: RE: [DG-AM] definition of Identity Attribute for the report OK, so x.1252 (not 1254 which is entity authentication assurance) does not specifically define ‘Identity attribute’. But I think the term can be derived from the following definitions. Arguably, the ‘NOTE’ is not helpful given some of the AM DG discussion. But overall, I think it is fair to say that the ITU-T definitions represent a reasonable compromise on the range of opinions expressed. Cheers Colin 6.30 identity: A representation of an entity in the form of one or more attributes that allow the entity or entities 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. NOTE – Each entity is represented by one holistic identity that comprises all possible information elements characterizing such entity (the attributes). However, this holistic identity is a theoretical issue and eludes any description and practical usage because the number of all possible attributes is indefinite. 6.9 attribute: Information bound to an entity that specifies a characteristic of the entity. From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Salvatore D'Agostino Sent: Tuesday, 27 March 2012 12:03 p.m. To: Joanne Knight; 'David L. Wasley'; dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report Agree that there is a distinction between “core identity” attributes and others that are acquired. Is this in x.1254? Let’s see if and how we can include the distinction. From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Joanne Knight Sent: Monday, March 26, 2012 4:47 PM To: 'David L. Wasley'; dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report There are two point I would pick up here. 1) If we define Identity Attribute as the values needed to establish that an individual entity in unique then adding attributes such as Student would mean an unnecessary number of attributes would need to be collected to achieive uniqueness. 2) As per previous email, we have moved further to a point where we consider Role or Context separately from unique identity. For example in an Education system one unique identity may have more than one role e.g. Student and Teacher. The identity is the same for both but the role they perform in different situations changes. We would attach rights and permissions to the combination of identity and role (personna) not to the identity on its own. Identifiers, facts and preferences may also be different depending on the role. e.g. Joe Bloggs teaches Mathematics but is learning how to paint. In his personna of Mathematics teacher his qualifications and use of the title Professor are relevant, when he is learning to paint he no longer wishes to be referred to as Professor and his mathematic and teaching qualifications are also unlikely to be relevant to his learning or ability to paint. Don't we want to move to an environment where a person can establish their unique identity and attach it to a credential that allows them to reuse this identity when registering with any organisation. If we encumber that identity with role information that is only relevant to one organisation or system context then I would suggest we would be designing a global service centric data store rather than a person centric ecosystem. Just my thoughts From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of David L. Wasley Sent: Friday, 23 March 2012 8:02 a.m. 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, Salvatore D'Agostino wrote: 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 Dagg, Kenneth 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 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 _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am ==== 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. ==== ==== 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. ====

David, Thanks for the comments. We took these up on the call today and will incorporate this, as we understand it, into the draft by next week's call. In particular under definition and recommendations. Sal From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of David L. Wasley Sent: Tuesday, March 27, 2012 1:26 PM To: Colin Wallis Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] definition of Identity Attribute for the report WRT : On Mar 26, 2012, at 4:24 PM, Colin Wallis wrote: OK, so x.1252 (not 1254 which is entity authentication assurance) does not specifically define 'Identity attribute'. But I think the term can be derived from the following definitions. Arguably, the 'NOTE' is not helpful given some of the AM DG discussion. But overall, I think it is fair to say that the ITU-T definitions represent a reasonable compromise on the range of opinions expressed. Cheers Colin 6.30 identity: A representation of an entity in the form of one or more attributes that allow the entity or entities 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. NOTE - Each entity is represented by one holistic identity that comprises all possible information elements characterizing such entity (the attributes). However, this holistic identity is a theoretical issue and eludes any description and practical usage because the number of all possible attributes is indefinite. 6.9 attribute: Information bound to an entity that specifies a characteristic of the entity. I think the above captures the essence. The NOTE is simply to recognize that there is no bound to this definition. So back to "attributes" which as I recall is the subject of this DG. Assuming that a Subject can legitimately "claim" an abstract identifier that is bound to a unique record in an IdMS, what "attributes" might be contained in that record? The issues that come to mind include: - semantics: how is an attribute defined such that a RP can understand what it might receive? E.g. "Name" -- is that Full Given Name at Birth, or ...? Etc. - syntax: how is the information presented to a RP? Is "age" "19" or "over 18" or "microseconds since birth" or ... - grammar: are there adjectives, e.g. Student; undergraduate; etc. - authoritativeness: how and when was that attribute acquired, determined and/or maintained? And how would an ISP convey that to an RP? Etc. David

I have very serious concerns about your perspective. In my world, what a relying party needs to know is seldom "absolute identity" but simply what "is true about the entity" in order to make an access management decision. The latter can be achieved in many ways. "Absolute identity" is whatever it takes to distinguish one entity from all others. DNA works pretty well. Driver's license, not so well. If "absolute" identity (AId) is able to be determined with relative ease, then we will have lost every vestige of privacy. Period. It will be used by every RP from the NSA to Google and Facebook. Recall how misused SSN became. Everything will be tied to AId. Everything you do will be correlatible. AId may be important in arresting someone but only if guilt was established in a way that tied to that identity. Almost everything else between a Subject and RP is relative, or contextually dependent. If I withdraw money fro an ATM, the "relative identity" is that I own that account number. If I go to a hospital for treatment, the relative identity is that I am the person with patient # 11235813. Perhaps we need to drop the use of "identity" altogether and use terms that are less ambiguous. The notion of an "Identity Service Provider" could become "Subject Information Provider" (SIP). AId would become "Globally Unique Identifier" (GUI). My ideal model of the person centric ecosystem is one in which I have strong, reliable credentials (plural) with which I can associate authoritative information acquired and held by one or more SIP(s). The set of information known to any given SIP would not necessarily be known by other SIPs. SIPs would be forbidden by law from colluding. I am given complete control of the release of my SIP information to RPs with which I wish to interact. None of this requires a GUI. David On Mar 26, 2012, at 1:47 PM, Joanne Knight wrote:

There are two point I would pick up here.

1) If we define Identity Attribute as the values needed to establish that an individual entity in unique then adding attributes such as Student would mean an unnecessary number of attributes would need to be collected to achieive uniqueness.

2) As per previous email, we have moved further to a point where we consider Role or Context separately from unique identity. For example in an Education system one unique identity may have more than one role e.g. Student and Teacher. The identity is the same for both but the role they perform in different situations changes. We would attach rights and permissions to the combination of identity and role (personna) not to the identity on its own. Identifiers, facts and preferences may also be different depending on the role. e.g. Joe Bloggs teaches Mathematics but is learning how to paint. In his personna of Mathematics teacher his qualifications and use of the title Professor are relevant, when he is learning to paint he no longer wishes to be referred to as Professor and his mathematic and teaching qualifications are also unlikely to be relevant to his learning or ability to paint.

Don't we want to move to an environment where a person can establish their unique identity and attach it to a credential that allows them to reuse this identity when registering with any organisation. If we encumber that identity with role information that is only relevant to one organisation or system context then I would suggest we would be designing a global service centric data store rather than a person centric ecosystem.

Just my thoughts

From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of David L. Wasley Sent: Friday, 23 March 2012 8:02 a.m. 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, Salvatore D'Agostino wrote:

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 Dagg, Kenneth 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 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

_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am

==== 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. ====