REMINDER & AGENDA - DG-AM call, 28-Feb-2012
Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Tuesday. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+201... * *Date:* Tuesday, February 28, 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 b. OIX-AX (guest, Don Thibeau) c. Meeting March 13?
Folks I read the latest draft over the weekend and have given it some surgery - knife, air supply (additions) and moving stuff around, getting more consistency :-). I have left some questions and checking work to do, but I think it's better overall. Do you agree? http://kantarainitiative.org/confluence/display/AMDG/Report+-+DRAFT Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Heather Flanagan Sent: Sunday, 26 February 2012 11:17 a.m. To: dg-am@kantarainitiative.org Cc: don.thibeau@openidentityexchange.org Subject: [DG-AM] REMINDER & AGENDA - DG-AM call, 28-Feb-2012 Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Tuesday. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+201... * *Date:* Tuesday, February 28, 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 b. OIX-AX (guest, Don Thibeau) c. Meeting March 13? _______________________________________________ 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. ====
Colin, Some initial comments on the draft report. I realize I haven't been a part of the discussion up to now but hope to be participating on a regular basis going forward. Missing Topic In my mind the Level of Assurance of an attribute should be a topic. That is, beyond the criteria contained in the SAC, what factors determine the level of assurance for an attribute. Does an attribute from a provider have a higher level of assurance if it was validated a year ago rather than 5 years ago. The question is: what factors are there (including range of values) and how many of them have to be satisfied for each level of assurance. Context Topic To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid). My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them. Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject. To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed. Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service. Query Language Topic I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?" To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol. I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own. 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 Colin Wallis Sent: February 26, 2012 7:53 PM To: dg-am@kantarainitiative.org Subject: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Folks I read the latest draft over the weekend and have given it some surgery - knife, air supply (additions) and moving stuff around, getting more consistency :-). I have left some questions and checking work to do, but I think it's better overall. Do you agree? http://kantarainitiative.org/confluence/display/AMDG/Report+-+DRAFT Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Heather Flanagan Sent: Sunday, 26 February 2012 11:17 a.m. To: dg-am@kantarainitiative.org Cc: don.thibeau@openidentityexchange.org Subject: [DG-AM] REMINDER & AGENDA - DG-AM call, 28-Feb-2012 Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Tuesday. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+201... * *Date:* Tuesday, February 28, 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 b. OIX-AX (guest, Don Thibeau) c. Meeting March 13? _______________________________________________ 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. ==== _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am
Many thanks for the feedback Ken Better late than never! :-) Heather's editing and the group may have a view, but some comments from me <<inline>> below Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Tuesday, 28 February 2012 10:03 a.m. To: Colin Wallis; dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Colin, Some initial comments on the draft report. I realize I haven't been a part of the discussion up to now but hope to be participating on a regular basis going forward. Missing Topic In my mind the Level of Assurance of an attribute should be a topic. That is, beyond the criteria contained in the SAC, what factors determine the level of assurance for an attribute. Does an attribute from a provider have a higher level of assurance if it was validated a year ago rather than 5 years ago. The question is: what factors are there (including range of values) and how many of them have to be satisfied for each level of assurance. <<CW: Umm..LoA is in there under Trust Frameworks (it was under Governance but I moved it). Did you see it? Or is it that you would like it as a separate topic - which is a fair point regardless..>> Context Topic To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid). My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them. Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject. To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed. Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service. <<CW: Good points and no disagreement with the distinction that could be added. But remember that the scope is not limited to Identity Assertions (at least not explicitly)>>. Query Language Topic I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?" To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol. I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own. <<CW: Fair point. The reason I think they were separated was because they felt the protocol part per se was stable, whereas the query language that would go into the protocol was not. If there were no other comments to the contrary, they could be pushed back together.>>. 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 Colin Wallis Sent: February 26, 2012 7:53 PM To: dg-am@kantarainitiative.org Subject: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Folks I read the latest draft over the weekend and have given it some surgery - knife, air supply (additions) and moving stuff around, getting more consistency :-). I have left some questions and checking work to do, but I think it's better overall. Do you agree? http://kantarainitiative.org/confluence/display/AMDG/Report+-+DRAFT Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Heather Flanagan Sent: Sunday, 26 February 2012 11:17 a.m. To: dg-am@kantarainitiative.org Cc: don.thibeau@openidentityexchange.org Subject: [DG-AM] REMINDER & AGENDA - DG-AM call, 28-Feb-2012 Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Tuesday. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+201... * *Date:* Tuesday, February 28, 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 b. OIX-AX (guest, Don Thibeau) c. Meeting March 13? _______________________________________________ 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. ==== _______________________________________________ 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 ==== 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. ====
Colin, My apologies with respect to LoA - I did miss it. Given that LoA is a key component of Trust Frameworks I don't think that it needs a topic of its own. I am in agreement with the recommendations and would suggest that the answer to your question is yes - the experience of the IAWG should be applied to evolving the existing LoA framework and SAC to accommodate attributes. 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 Colin Wallis Sent: February 27, 2012 6:38 PM To: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Many thanks for the feedback Ken Better late than never! :-) Heather's editing and the group may have a view, but some comments from me <<inline>> below Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Tuesday, 28 February 2012 10:03 a.m. To: Colin Wallis; dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Colin, Some initial comments on the draft report. I realize I haven't been a part of the discussion up to now but hope to be participating on a regular basis going forward. Missing Topic In my mind the Level of Assurance of an attribute should be a topic. That is, beyond the criteria contained in the SAC, what factors determine the level of assurance for an attribute. Does an attribute from a provider have a higher level of assurance if it was validated a year ago rather than 5 years ago. The question is: what factors are there (including range of values) and how many of them have to be satisfied for each level of assurance. <<CW: Umm..LoA is in there under Trust Frameworks (it was under Governance but I moved it). Did you see it? Or is it that you would like it as a separate topic - which is a fair point regardless..>> Context Topic To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid). My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them. Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject. To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed. Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service. <<CW: Good points and no disagreement with the distinction that could be added. But remember that the scope is not limited to Identity Assertions (at least not explicitly)>>. Query Language Topic I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?" To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol. I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own. <<CW: Fair point. The reason I think they were separated was because they felt the protocol part per se was stable, whereas the query language that would go into the protocol was not. If there were no other comments to the contrary, they could be pushed back together.>>. 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 Colin Wallis Sent: February 26, 2012 7:53 PM To: dg-am@kantarainitiative.org Subject: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Folks I read the latest draft over the weekend and have given it some surgery - knife, air supply (additions) and moving stuff around, getting more consistency :-). I have left some questions and checking work to do, but I think it's better overall. Do you agree? http://kantarainitiative.org/confluence/display/AMDG/Report+-+DRAFT Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Heather Flanagan Sent: Sunday, 26 February 2012 11:17 a.m. To: dg-am@kantarainitiative.org Cc: don.thibeau@openidentityexchange.org Subject: [DG-AM] REMINDER & AGENDA - DG-AM call, 28-Feb-2012 Hi all - Just a reminder: we have our Attribute Management Discussion Group call this Tuesday. Agenda is online in detail, with summary below. http://kantarainitiative.org/confluence/display/AMDG/AMDG+Meeting+Agenda+201... * *Date:* Tuesday, February 28, 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 b. OIX-AX (guest, Don Thibeau) c. Meeting March 13? _______________________________________________ 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. ==== _______________________________________________ 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 ==== 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
Ken, Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard. Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice. Is there somewhere a definition of an asserted, validated and assured attribute? - Rainer Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
Rainer, Some thoughts that your comments stired up. The terms I am proposing are the following: Identity Assertion Provider: provides an assertion that someone's identity is valid. This assertion is made to a level of assurance (criteria need to be determined). In my mind, the provider is able to assert someone's identity in the context in which they validated it. Identity Attribute Provider: provides an actual attribute (or possibly a set of attributes) and a level of assurance of the attribute(s) (the criteria for each LoA need to be determined). An example of this would be the value 22 to a query, "what is John's age?" Identity Attribute Validation Provider: provides an assertion concerning an attribute without providing the attribute. An example, when John is 22, would be the answer Yes (to a LoA) to the query, "is John over the age of 18?" The validation could also be for a set of attributes. For example, a response could validate that John Smith, 22, and 123 Anywhere Lane (these form part of a query) are a valid set of attributes without providing the actual attributes or any other attributes held by the provider. The service provider could then make a decision as to the identity of the individual they have in front of them (physically or electronically). This puts the risk on the service provider (where I believe it belongs) to ensure that they verify the identity of an individual in the context that they exist based upon assertions on a number (that they determine) of attributes. Both of these types of providers could be the same organization though they might be different). The real difference is the type of query being responded to. Both types act as Authoritative Parties. You raise an interesting concept - the doctor that is making a claim about the age of the patient. As a thought, is the doctor not fulfilling the role of an Identity Attribute (Validation) Provider when making this claim? If this is the case, then the doctor needs to have a LoA associated with the claim. In fact, is the claim made by the doctor not the same type of claim as the claim made someone who fulfils the role of guarantor on a passport application? My concern is with the Identity Assertion Provider. The assertion, in my mind, is very dependent on the context in which an individual's identity is validated by the Identity Assertion Provider so that they can make an assertion. This context really needs to be understood by the party that will be relying upon the assertion in order that they can rely upon it. As I said above, I believe that the risk associated with context should be with the service provider rather than the identity provider. The identity provider should just be an authoritative party about a set of identity attributes. In this model, a service provider could even go to several attribute authoritative parties for the same attribute if they wanted multiple confirmations. I need to think about these concepts more and invite comment. 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 Rainer Hoerbe Sent: February 28, 2012 4:05 PM To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Ken, Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard. Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice. Is there somewhere a definition of an asserted, validated and assured attribute? - Rainer Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am
Hi Trying to catch up, Apologies for duplications or errors.... --- Agree with Ken remarks, the assertion is depend on context. And for an RP, it should have the ability to validate the assertion (for a given LoA) from different sources (if possible and yes under user control (if possible)). At the end of the day the liability is on the RP to make a decision whether it would offer the service or not. Even within the same Trust Framework, the RP should treat the assertions as input to internal risk engine and based on the outcome the RP will decide the next steps. So within the same Trust Framework, the RP may trust one entity (IAP) more than other based on context, previous business experience, the location of a transaction and may ROI. Regards abbie -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Tuesday, February 28, 2012 5:46 PM To: 'Rainer Hoerbe' Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Rainer, Some thoughts that your comments stired up. The terms I am proposing are the following: Identity Assertion Provider: provides an assertion that someone's identity is valid. This assertion is made to a level of assurance (criteria need to be determined). In my mind, the provider is able to assert someone's identity in the context in which they validated it. Identity Attribute Provider: provides an actual attribute (or possibly a set of attributes) and a level of assurance of the attribute(s) (the criteria for each LoA need to be determined). An example of this would be the value 22 to a query, "what is John's age?" Identity Attribute Validation Provider: provides an assertion concerning an attribute without providing the attribute. An example, when John is 22, would be the answer Yes (to a LoA) to the query, "is John over the age of 18?" The validation could also be for a set of attributes. For example, a response could validate that John Smith, 22, and 123 Anywhere Lane (these form part of a query) are a valid set of attributes without providing the actual attributes or any other attributes held by the provider. The service provider could then make a decision as to the identity of the individual they have in front of them (physically or electronically). This puts the risk on the service provider (where I believe it belongs) to ensure that they verify the identity of an individual in the context that they exist based upon assertions on a number (that they determine) of attributes. Both of these types of providers could be the same organization though they might be different). The real difference is the type of query being responded to. Both types act as Authoritative Parties. You raise an interesting concept - the doctor that is making a claim about the age of the patient. As a thought, is the doctor not fulfilling the role of an Identity Attribute (Validation) Provider when making this claim? If this is the case, then the doctor needs to have a LoA associated with the claim. In fact, is the claim made by the doctor not the same type of claim as the claim made someone who fulfils the role of guarantor on a passport application? My concern is with the Identity Assertion Provider. The assertion, in my mind, is very dependent on the context in which an individual's identity is validated by the Identity Assertion Provider so that they can make an assertion. This context really needs to be understood by the party that will be relying upon the assertion in order that they can rely upon it. As I said above, I believe that the risk associated with context should be with the service provider rather than the identity provider. The identity provider should just be an authoritative party about a set of identity attributes. In this model, a service provider could even go to several attribute authoritative parties for the same attribute if they wanted multiple confirmations. I need to think about these concepts more and invite comment. 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 Rainer Hoerbe Sent: February 28, 2012 4:05 PM To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Ken, Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard. Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice. Is there somewhere a definition of an asserted, validated and assured attribute? - Rainer Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
_______________________________________________ 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 ---------------------------------------------------------------------- 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.
Hi, I agree fully that the liability is with the RP to make the decision on whether or not to deliver the service. I also agree with the RP being able to check identity (or personal information) from as many authoritative sources as they deem necessary to have an acceptable level of risk to deliver service to a client. It's their call (and their expense) as to the level of assurance they demand from each source. As such, I don't believe that identity attribute management has to worry whether ten (or however many) attribute checks at LoA1 is the same as a one at LoA4. This is a risk management decision the RP has to make. I believe that in making the determination of which and how many, the RP looks at three things: 1) is the client eligible to receive the service 2) do we (RP) have all the information we need to provide an output (product or service) 3) do we have all the information to deliver the output to the client The answers to each of these questions involves having or collecting personal information about the client. For example, to perform an operation on an individual · To determine eligibility: proof of ability to pay from either an insurance card or a credit card. · To uniquely identify: The hospital asks for the patient's (client's) name, gender, address, and telephone number which they check against the record the health insurance provider holds on the patient (as indexed by, for example, their health card number). I'm not sure what they want from people that do not have a health insurance card. · To verify identity in the operating room: the surgeon examines a hospital supplied wrist band, a mark made by surgeon where the operation is to be performed. · To deliver services: the surgeon examines diagnostic information gathered in a variety of ways (e.g., doctor's notes, diagnostic images, lab results) In this example I believe that the following are all personal information: - patient's (client's) name, gender, address, and telephone number - jurisdiction's record on the individual - hospital supplied wrist band - mark on the patient - doctor's notes about the patient, - diagnostic images of the patient, - lab results for the patient Regardless of what of this personal information is identity information for this service I would suggest (or at least I would hope) that the level of assurance (i.e., the trust the service deliverer) has in the information has to be quite high in order to have the service delivered. In my mind the level of trust, or the level of assurance, associated with this information (whether identity or personal) is the same and thus the information should be treated in the same manner. Part of the discussion here revolves around personal information associated with an individual and personal information about an individual. 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: Barbir, Abbie [mailto:abbie.barbir@bankofamerica.com] Sent: March 2, 2012 9:49 AM To: Dagg, Kenneth; 'Rainer Hoerbe' Cc: dg-am@kantarainitiative.org Subject: RE: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Hi Trying to catch up, Apologies for duplications or errors.... --- Agree with Ken remarks, the assertion is depend on context. And for an RP, it should have the ability to validate the assertion (for a given LoA) from different sources (if possible and yes under user control (if possible)). At the end of the day the liability is on the RP to make a decision whether it would offer the service or not. Even within the same Trust Framework, the RP should treat the assertions as input to internal risk engine and based on the outcome the RP will decide the next steps. So within the same Trust Framework, the RP may trust one entity (IAP) more than other based on context, previous business experience, the location of a transaction and may ROI. Regards abbie -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Dagg, Kenneth Sent: Tuesday, February 28, 2012 5:46 PM To: 'Rainer Hoerbe' Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Rainer, Some thoughts that your comments stired up. The terms I am proposing are the following: Identity Assertion Provider: provides an assertion that someone's identity is valid. This assertion is made to a level of assurance (criteria need to be determined). In my mind, the provider is able to assert someone's identity in the context in which they validated it. Identity Attribute Provider: provides an actual attribute (or possibly a set of attributes) and a level of assurance of the attribute(s) (the criteria for each LoA need to be determined). An example of this would be the value 22 to a query, "what is John's age?" Identity Attribute Validation Provider: provides an assertion concerning an attribute without providing the attribute. An example, when John is 22, would be the answer Yes (to a LoA) to the query, "is John over the age of 18?" The validation could also be for a set of attributes. For example, a response could validate that John Smith, 22, and 123 Anywhere Lane (these form part of a query) are a valid set of attributes without providing the actual attributes or any other attributes held by the provider. The service provider could then make a decision as to the identity of the individual they have in front of them (physically or electronically). This puts the risk on the service provider (where I believe it belongs) to ensure that they verify the identity of an individual in the context that they exist based upon assertions on a number (that they determine) of attributes. Both of these types of providers could be the same organization though they might be different). The real difference is the type of query being responded to. Both types act as Authoritative Parties. You raise an interesting concept - the doctor that is making a claim about the age of the patient. As a thought, is the doctor not fulfilling the role of an Identity Attribute (Validation) Provider when making this claim? If this is the case, then the doctor needs to have a LoA associated with the claim. In fact, is the claim made by the doctor not the same type of claim as the claim made someone who fulfils the role of guarantor on a passport application? My concern is with the Identity Assertion Provider. The assertion, in my mind, is very dependent on the context in which an individual's identity is validated by the Identity Assertion Provider so that they can make an assertion. This context really needs to be understood by the party that will be relying upon the assertion in order that they can rely upon it. As I said above, I believe that the risk associated with context should be with the service provider rather than the identity provider. The identity provider should just be an authoritative party about a set of identity attributes. In this model, a service provider could even go to several attribute authoritative parties for the same attribute if they wanted multiple confirmations. I need to think about these concepts more and invite comment. 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 Rainer Hoerbe Sent: February 28, 2012 4:05 PM To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Ken, Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard. Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice. Is there somewhere a definition of an asserted, validated and assured attribute? - Rainer Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
_______________________________________________ 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 ---------------------------------------------------------------------- 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.
Ken, What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes? I also wonder if we need to impose a restriction to an attribute provider to be only an "Identity Attribute Provider". Is an affiliation or a role an identity attribute? A case number in a hospital, which is meant to be temporal? Credit rating? Regarding context: I agree that context is relevant. For the purpose of automated access decisions the context either needs to be described in the assertion or the policy. Or the federation is limited to a set of parties who operate in a known or regulated context. Best regards Rainer Am 28.02.2012 um 14:46 schrieb Dagg, Kenneth:
Rainer,
Some thoughts that your comments stired up.
The terms I am proposing are the following:
Identity Assertion Provider: provides an assertion that someone's identity is valid. This assertion is made to a level of assurance (criteria need to be determined). In my mind, the provider is able to assert someone's identity in the context in which they validated it.
Identity Attribute Provider: provides an actual attribute (or possibly a set of attributes) and a level of assurance of the attribute(s) (the criteria for each LoA need to be determined). An example of this would be the value 22 to a query, "what is John's age?"
Identity Attribute Validation Provider: provides an assertion concerning an attribute without providing the attribute. An example, when John is 22, would be the answer Yes (to a LoA) to the query, "is John over the age of 18?" The validation could also be for a set of attributes. For example, a response could validate that John Smith, 22, and 123 Anywhere Lane (these form part of a query) are a valid set of attributes without providing the actual attributes or any other attributes held by the provider. The service provider could then make a decision as to the identity of the individual they have in front of them (physically or electronically). This puts the risk on the service provider (where I believe it belongs) to ensure that they verify the identity of an individual in the context that they exist based upon assertions on a number (that they determine) of attributes.
Both of these types of providers could be the same organization though they might be different). The real difference is the type of query being responded to. Both types act as Authoritative Parties.
You raise an interesting concept - the doctor that is making a claim about the age of the patient. As a thought, is the doctor not fulfilling the role of an Identity Attribute (Validation) Provider when making this claim? If this is the case, then the doctor needs to have a LoA associated with the claim. In fact, is the claim made by the doctor not the same type of claim as the claim made someone who fulfils the role of guarantor on a passport application?
My concern is with the Identity Assertion Provider. The assertion, in my mind, is very dependent on the context in which an individual's identity is validated by the Identity Assertion Provider so that they can make an assertion. This context really needs to be understood by the party that will be relying upon the assertion in order that they can rely upon it. As I said above, I believe that the risk associated with context should be with the service provider rather than the identity provider. The identity provider should just be an authoritative party about a set of identity attributes. In this model, a service provider could even go to several attribute authoritative parties for the same attribute if they wanted multiple confirmations.
I need to think about these concepts more and invite comment.
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 Rainer Hoerbe Sent: February 28, 2012 4:05 PM To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012)
Ken,
Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard.
Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice.
Is there somewhere a definition of an asserted, validated and assured attribute?
- Rainer
Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
_______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am
Personal views (as as they nearly all are these days.. :-)) << What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes?>> CW: Needed because they are slightly different roles and the these attribute providers are not necessarily the same for all the reasons stated. From the SP/RP's viewpoint, it would be easier to have this distinction IMHO. << I also wonder if we need to impose a restriction to an attribute provider to be only an "Identity Attribute Provider". Is an affiliation or a role an identity attribute? A case number in a hospital, which is meant to be temporal? Credit rating?>> CW: Agreed. This is one of the things (identity *related* aggregation to build to an acceptable LoA) that the social networks are teaching us about identity confirmation, in the absence of authoritative sources. Whether the Googles, Facebooks Apples and Amazons are with forces they are today in 10 years time is arguably not as relevant as the legacy 'patterns' that they might leave behind. <<Regarding context: I agree that context is relevant. For the purpose of automated access decisions the context either needs to be described in the assertion or the policy. Or the federation is limited to a set of parties who operate in a known or regulated context.>> CW: Agreed, and to my knowledge this is the opinion of everyone on the AMDG list. Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Rainer Hoerbe Sent: Saturday, 3 March 2012 2:06 p.m. To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Ken, What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes? I also wonder if we need to impose a restriction to an attribute provider to be only an "Identity Attribute Provider". Is an affiliation or a role an identity attribute? A case number in a hospital, which is meant to be temporal? Credit rating? Regarding context: I agree that context is relevant. For the purpose of automated access decisions the context either needs to be described in the assertion or the policy. Or the federation is limited to a set of parties who operate in a known or regulated context. Best regards Rainer Am 28.02.2012 um 14:46 schrieb Dagg, Kenneth:
Rainer,
Some thoughts that your comments stired up.
The terms I am proposing are the following:
Identity Assertion Provider: provides an assertion that someone's identity is valid. This assertion is made to a level of assurance (criteria need to be determined). In my mind, the provider is able to assert someone's identity in the context in which they validated it.
Identity Attribute Provider: provides an actual attribute (or possibly a set of attributes) and a level of assurance of the attribute(s) (the criteria for each LoA need to be determined). An example of this would be the value 22 to a query, "what is John's age?"
Identity Attribute Validation Provider: provides an assertion concerning an attribute without providing the attribute. An example, when John is 22, would be the answer Yes (to a LoA) to the query, "is John over the age of 18?" The validation could also be for a set of attributes. For example, a response could validate that John Smith, 22, and 123 Anywhere Lane (these form part of a query) are a valid set of attributes without providing the actual attributes or any other attributes held by the provider. The service provider could then make a decision as to the identity of the individual they have in front of them (physically or electronically). This puts the risk on the service provider (where I believe it belongs) to ensure that they verify the identity of an individual in the context that they exist based upon assertions on a number (that they determine) of attributes.
Both of these types of providers could be the same organization though they might be different). The real difference is the type of query being responded to. Both types act as Authoritative Parties.
You raise an interesting concept - the doctor that is making a claim about the age of the patient. As a thought, is the doctor not fulfilling the role of an Identity Attribute (Validation) Provider when making this claim? If this is the case, then the doctor needs to have a LoA associated with the claim. In fact, is the claim made by the doctor not the same type of claim as the claim made someone who fulfils the role of guarantor on a passport application?
My concern is with the Identity Assertion Provider. The assertion, in my mind, is very dependent on the context in which an individual's identity is validated by the Identity Assertion Provider so that they can make an assertion. This context really needs to be understood by the party that will be relying upon the assertion in order that they can rely upon it. As I said above, I believe that the risk associated with context should be with the service provider rather than the identity provider. The identity provider should just be an authoritative party about a set of identity attributes. In this model, a service provider could even go to several attribute authoritative parties for the same attribute if they wanted multiple confirmations.
I need to think about these concepts more and invite comment.
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 Rainer Hoerbe Sent: February 28, 2012 4:05 PM To: Dagg, Kenneth Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012)
Ken,
Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard.
Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice.
Is there somewhere a definition of an asserted, validated and assured attribute?
- Rainer
Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.
_______________________________________________ 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 ==== 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. ====
Am 05.03.2012 um 01:32 schrieb Colin Wallis:
<< RH: What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes?>>
CW: Needed because they are slightly different roles and the these attribute providers are not necessarily the same for all the reasons stated. From the SP/RP's viewpoint, it would be easier to have this distinction IMHO.
Can you provide a use case? I am still missing the point - Rainer
I ran it through a use case. Point taken. I hereby withdraw that comment. There's a case for separation (by the expected LoA of the attribute from a particular provider) just to assist with the comparison and eventual decision by the SP, but it's relatively trivial in the scheme of things. Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Rainer Hoerbe Sent: Monday, 5 March 2012 5:12 p.m. To: Colin Wallis Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Am 05.03.2012 um 01:32 schrieb Colin Wallis:
<< RH: What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes?>>
CW: Needed because they are slightly different roles and the these attribute providers are not necessarily the same for all the reasons stated. >From the SP/RP's viewpoint, it would be easier to have this distinction IMHO.
Can you provide a use case? I am still missing the point - Rainer _______________________________________________ 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. ====
participants (5)
-
Barbir, Abbie -
Colin Wallis -
Dagg, Kenneth -
Heather Flanagan -
Rainer Hoerbe