Mark,<div><br></div><div>I have excluded Danny from this response as I don&#39;t believe he needs to be part of the nitty-gritty ... just the end result.</div><div><br></div><div>I agree fully that consent is an integral part of how someone copes with multiple personas. However, at least in my opinion, it is only one contributor (albeit a significant one) to the equation. For example, I consent to attribute exchange but the RP violates privacy practices and discloses or misuses the attributes or bypasses ongoing consent requirements using their own technical solutions (i.e., they do not use systems based on consent management standards).</div><div><br></div><div>I believe that consent is implied in the final paragraph of what I prepared. If you have improvements to that paragraph to highlight consent please suggest them and I&#39;ll be happy to incorporate.</div><div><br></div><div>Ken</div><div><br>On Friday, 26 February 2016, Mark Lizar - OCG &lt;<a href="mailto:m.lizar@openconsentgroup.com">m.lizar@openconsentgroup.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Thats a great question Ken. Finally, one that gets more into Consent &amp; Information Sharing Work. </div><div><br></div>In terms of how we (the person behind the identity) copes with multiple attributes from multiple domains in ID management is with consent.  Where the individual is the point of attribute integration and dynamic persona development.  Consent management I would describe as the emerging field of attribute exchange via the individual.  <div><br></div><div><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div><div>Mark Lizar</div><div>Executive Director</div><div>Open Consent Group</div><div><br></div><div>Email: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;m.lizar@openconsentgroup.com&#39;);" target="_blank">m.lizar@openconsentgroup.com</a></div><div>Mobile: +447738382658</div></div><div>Twitter: @smartopian</div></div></div></div>
</div>
<br><div><blockquote type="cite"><div>On 26 Feb 2016, at 12:04, Ken Dagg &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kendaggtbs@gmail.com&#39;);" target="_blank">kendaggtbs@gmail.com</a>&gt; wrote:</div><br><div><div>Danny,</div><div><br></div><div>Another input for the article.</div><div><br></div><div>In response to the question, &quot;My identity as my wife sees it may be different to my identity as my bank sees it, which may be different again to my identity as my employer sees it. How do we cope with multiple attributes in ID management?&quot;</div><div><br></div><div>Ken Dagg</div><div><br></div><div>==================</div><div><br></div><div>Identity Management thinking is beginning to recognize that who an individual is (e.g., their identity) is dependent on the scenario in which that individual needs to assert who they are. Who you are, and how you represent yourself, in social situations, work situations and commercial situations is probably different - but all are just different representations or variations of who you are as an individual - different personas. That is, a persona is what you tell someone about yourself in order to interact with them.</div><div><br></div><div>For example, in order for you to be able to establish an account, and carry out financial transactions, with a bank requires that the bank know certain information (i.e., attributes) about you. Some of this information is required in order for the bank to deal with you effectively while other information is required to satisfy legal requirements. Your employer also requires specific attributes about you in order to have you as an employee (i.e., to pay you, to provide benefits, to provide work facilities). While there may be some overlaps between the sets of attributes required to satisfy these two relationships there are most likely differences. What is emerging is that 1) the required attributes are defined by and specific to the relationship and 2) there is no one representation that satisfies all requirements.</div><div><br></div><div>As such, the relationship you want to establish identifies the required attributes (i.e., your &quot;persona&quot;) and manages them to accomplish the purpose that the relationship exists to perform. As the consumer - the Relying Party (RP) - of your persona (e.g., the bank) is at risk, they authenticate and manage the set of attributes they require of you in order to mitigate the risk of getting it wrong. That is, the RP manages the identity of its clients to the degree they need to in order to operate. It is essential that the RP undertake a risk assessment to identify the consequences - financial and reputational - they will suffer if they misidentify someone and then establish, at a cost they believe is affordable, the mechanisms they believe will mitigate that risk. </div><div><br></div><div>The set of mechanisms the RP uses - the level of assurance they require - to mitigate their risk depend on the consequences they will suffer if they get it wrong (i.e., they misidentify you). These mechanisms can include doing nothing, using internal checks, using Social Media sites, using Government Agencies, or using companies that have established themselves as Identity Providers (IdPs), Credential Service Providers (CSPs), or Attribute Providers (APs). </div><div><br></div><div>Of importance to you as an individual, however, is knowing, and being able to correct errors in, the information / attributes the RP maintains about you as well as being assured that the RP respects your privacy.</div><div><br></div>
<br><br>-- <br>Kenneth Dagg<br>Independent Consultant<br>Identification and Authentication<br>613-825-2091<br><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kendaggtbs@gmail.com&#39;);" target="_blank">kendaggtbs@gmail.com</a><br>
_______________________________________________<br>LC mailing list<br><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;LC@kantarainitiative.org&#39;);" target="_blank">LC@kantarainitiative.org</a><br><a href="http://kantarainitiative.org/mailman/listinfo/lc" target="_blank">http://kantarainitiative.org/mailman/listinfo/lc</a><br></div></blockquote></div><br></div></div></blockquote></div><br><br>-- <br>Kenneth Dagg<br>Independent Consultant<br>Identification and Authentication<br>613-825-2091<br><a href="mailto:kendaggtbs@gmail.com">kendaggtbs@gmail.com</a><br>