March 2012 - DG-AM - mailman.kantarainitiative.org

Put IIW notes up
by Salvatore D'Agostino 28 Mar '12

28 Mar '12

http://kantarainitiative.org/confluence/display/AMDG/Current+Industry+Effort s under other Salvatore D'Agostino, CSCIP IDmachines LLC |1264 Beacon Street, #5 | Brookline, MA 02446 | USA http:\\www.idmachines.com <http://www.idmachines.com/> | http:\\idmachines.blogspot.com <http://idmachines.blogspot.com/> | @idmachines +1 617.201.4809 ph | +1 617.812.6495 fax

2 1

review of draft report (from Ken Dagg)...
by Anna Ticktin 27 Mar '12

27 Mar '12

> From: "Dagg, Kenneth" <Kenneth.Dagg(a)tbs-sct.gc.ca> > Date: 27March2012 1:05:07 PM PDT > To: "'dg-am-bounces(a)kantarainitiative.org'" <dg-am-bounces(a)kantarainitiative.org> > Subject: review of draft report > > > In reviewing the current version (#55) I could not see the following work that was identified in the gap discussion in the recommendations section: > Under coordination there needs to be something around coordinating the development and normalization of terms and definitions > Under needs there needs to be something around developing a classification system for business processes including and understanding of the attributes needed by each > Under context there needs to be something around understanding the set of attributes associated with each context (establishing a unique identity?) > Under query language there needs to be something around protocols to transmit attribute assertions > I think there is a missing recommendation around consent that could be along the lines of coordinating with the P2WG or possibly charging the P3WG with this task > > 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(a)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 > > > > > > >

1 0

definition of Identity Attribute for the report
by Dagg, Kenneth 27 Mar '12

27 Mar '12

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(a)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]

9 21

REMINDER & AGENDA: DG-AM call, 2012-03-27
by Heather Flanagan 27 Mar '12

27 Mar '12

Hi all - Just a reminder: we have our Attribute Management Discussion Group call this week. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+20… * *Date:* Tuesday, March 27, 2012 (?) * Time: 11h PT / 14h ET / 19h UTC * Dial in: * Skype: +99051000000481 * US Dial-In: +1-805-309-2350 | Room Code: 613-2898 AGENDA: 1. Administrative a. Roll Call b. New member introduction - no new members c. Agenda confirmation d. Action item review 2. Discussion a. Report Draft i. info added on LOA ii. attribute definition iii. other updates

1 0

Addition to Report
by Colin Wallis 26 Mar '12

26 Mar '12

Folks I've just added the substance of this issue: http://blog.idmanagement.gov/2012/03/to-loa-or-not-to-loa-for-attributes-no… to both the 'space' gaps and the recommendations, and confirmed a few ?? areas on my way through. cheers colin

1 0

FW: definition of Identity Attribute for the report
by Dagg, Kenneth 23 Mar '12

23 Mar '12

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(a)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 [cid:image001.gif@01CD08DC.62A2DBC0] ________________________________ From: dg-am-bounces(a)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(a)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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto: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(a)tbs-sct.gc.ca<mailto: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(a)kantarainitiative.org<mailto: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(a)kantarainitiative.org<mailto:DG-AM@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-am

1 0

FW: [T17Q10] LDAP is part of new IETF cloud identity charter
by Colin Wallis 22 Mar '12

22 Mar '12

I hope ITU-T won't mind this cross post. But for reasons we discussed earlier in the week, you can see why it might be important to some folks to include LDAP in the Report. Cheers Colin From: Erik Andersen [mailto:era@x500.eu] Sent: Friday, 23 March 2012 1:38 a.m. To: tony(a)yaanatech.com; t09sg17q11(a)lists.itu.int; t09sg17q10(a)lists.itu.int; Directory list Subject: SV: [T17Q10] LDAP is part of new IETF cloud identity charter Hi Tony, Thanks a lot for the information. As you know, LDAP is a dear child of X.500 and with the seventh edition, we have interworking with LDAP. X.500 vendors market their products as IdM system. I once went through a large number of IdM implementations and they all used directory, mostly LDAP and in particular Microsoft's Active Directory. I have always tried to tell people that directory, including X.509, is IdM. People do not listen, so I have given up and concentrate on my question, where we have our plate full, anyway. I will have to get on the SCIM list. Erik Fra: Tony Rutkowski [mailto:tony@yaanatech.com] Sendt: 22. marts 2012 12:25 Til: era(a)x500.eu; t09sg17q11(a)lists.itu.int; t09sg17q10(a)lists.itu.int Emne: [T17Q10] LDAP is part of new IETF cloud identity charter Hi Erik, Don't know if you're on the IETF SCIM list. It's very active and they are ramping up their cloud IdM work for the meeting next week in Paris. It's worth noting that they are proposing a LDAP binding. Lots of new cloud security and IdM work. SG13 will have its hands full in collaborating. best, tony --- 47,55 ---- identities as part of the work adopted by the working group. The group will use, as starting points, the following drafts in the following ways: ! draft-scim-use-cases-00 as the initial use cases for SCIM, ! draft-scim-core-schema-00 as the schema specification, ! draft-scim-api-00 as the protocol specification, draft-XXX-scim-saml-binding-00 for binding the SCIM schema to SAML, and draft-XXX-scim-ldap-binding-00 for binding the SCIM schema to LDAP. ==== 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. ====

1 0

REMINDER & AGENDA: DG-AM call, 21-Mar-2012
by Heather Flanagan 21 Mar '12

21 Mar '12

Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Wednesday (an out-of-sequence call). Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+20… * *Date:* Wednesday, March 21, 2012 (?) * *Time:* 12h PT / 15h ET / 19h UTC * Dial in: * Skype: \+99051000000481 * US Dial-In: \+1-805-309-2350 \| Room Code: 613-2898 AGENDA: 1. Administrative a. Roll Call b. New member introduction - no new members c. Agenda confirmation d. Action item review 2. Discussion a. IDTrust week b. Report Draft

2 1

AMDG call for next week
by Heather Flanagan 16 Mar '12

16 Mar '12

Hello all - Based on the responses to the doodle poll, it looks like our best time will be Wednesday March 21 @ 12pm PDT / 3pm EDT. I will send out the call details on Monday. Main topics: the report and an update on the attribute workshop and IDTrust. -Heather

2 1

upcoming meeting schedule and doodle poll
by Heather Flanagan 13 Mar '12

13 Mar '12

Hi all - Our next regularly scheduled meeting is this coming Tuesday, 13 March. That time slot conflicts with the first day of the ID Trust meeting, and I believe a significant number of you (most of the voting members, in fact) are going to be at that meeting. So, I propose the following: we will cancel the call for next week, and aim for an ad hoc call for the week after. Below is a doodle poll to find out what time might work for the most interested parties. Please respond to that poll no later than Wednesday, 14 March (COB) and I'll send out the results. http://www.doodle.com/ckma2v4pvttw224q If you haven't updated the draft report in the wiki with your thoughts, please do so this coming week. The goal is to have a final draft ready to go by the end of this month. Thanks! Heather

1 1