[KI-LC] SC Magazine Feature

Ken Dagg kendaggtbs at gmail.com
Fri Feb 26 06:40:22 CST 2016


I have excluded Danny from this response as I don't believe he needs to be
part of the nitty-gritty ... just the end result.

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

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'll be happy to incorporate.


On Friday, 26 February 2016, Mark Lizar - OCG <m.lizar at openconsentgroup.com>

> Thats a great question Ken. Finally, one that gets more into Consent &
> Information Sharing Work.
> 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.
> Mark Lizar
> Executive Director
> Open Consent Group
> Email: m.lizar at openconsentgroup.com
> <javascript:_e(%7B%7D,'cvml','m.lizar at openconsentgroup.com');>
> Mobile: +447738382658
> Twitter: @smartopian
> On 26 Feb 2016, at 12:04, Ken Dagg <kendaggtbs at gmail.com
> <javascript:_e(%7B%7D,'cvml','kendaggtbs at gmail.com');>> wrote:
> Danny,
> Another input for the article.
> In response to the question, "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?"
> Ken Dagg
> ==================
> 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.
> 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.
> As such, the relationship you want to establish identifies the required
> attributes (i.e., your "persona") 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.
> 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).
> 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.
> --
> Kenneth Dagg
> Independent Consultant
> Identification and Authentication
> 613-825-2091
> kendaggtbs at gmail.com
> <javascript:_e(%7B%7D,'cvml','kendaggtbs at gmail.com');>
> _______________________________________________
> LC mailing list
> LC at kantarainitiative.org
> <javascript:_e(%7B%7D,'cvml','LC at kantarainitiative.org');>
> http://kantarainitiative.org/mailman/listinfo/lc

Kenneth Dagg
Independent Consultant
Identification and Authentication
kendaggtbs at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/lc/attachments/20160226/00d43162/attachment.html>

More information about the LC mailing list