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
-----Original Message-----
From: Barbir, Abbie [mailto:abbie.barbir@bankofamerica.com]
Sent: March 2, 2012 9:49 AM
To:
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
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:
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
> 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.