Sorry I missed the call tonight, will pick up on Friday.
Regards Stuart
On Wed, 30 Jan 2019, 19:01 John Callahan It's almost time for our call, but I love the discussion. We're closer
than we think around Joe's proposed clarification IMHO. For example, Richard's comment "Further, assurance is not the process.
Assurance is the degree of trust/confidence one can have that *the
process was correctly and competently applied*..." actually agrees with
Joe's definition "identity assurance is the *documented process* assuring
that identity proofing occurred according to policy" if interpreted as the
documenting of a process application. -- jack John Callahan, PhD Chief Technology Officer C: 415.684.8467
E: jcallahan@veridiumid.com [image: Veridium] http://www.veridiumid.com 1177 Avenue of the Americas | 5th Floor
New York, NY 10036 | USA
[image: LinkedIn] https://www.linkedin.com/company/veridium [image:
Twitter] https://twitter.com/veridiumid [image: Facebook]
https://facebook.com/veridiumid On Wed, Jan 30, 2019 at 11:21 AM Richard G. WILSHER (@Zygma) <
RGW@zygma.biz> wrote: An interesting thread … but painful, as glossarial efforts always are.
I’m not sure if this contribution does anything more than serve just to
emphasis the difficulty in such work, but I find a number of definitions in
this thread troublesome. I suspect that trying to fix it piecemeal If
*identity - *set of attributes related to an entity and *known entity - *an entity with an identity in a system then by substitution *known entity - *an entity with a [set of attributes related to an
entity ] in a system which is a mess, and could be taken to imply that entity-A has a set of
attributes related to an[other] entity-B, since there is nothing to bind
the two instances of ‘entity’, so what about: *known entity – *a set of attributes related to an entity [recognized?]
in a system but at the same time, what merit in being ‘known’ – does that mean that
the entity has been proofed and accepted as a ‘proven’ or ‘accepted’
identity within the context of applicable policies etc.? And what system?
We presumably need a reference system, the ‘given system’, since the mere
fact that I have a DL means that I am a known entity in the CA’s DMV system
but not necessarily elsewhere, i.e. in other ‘systems’. Or perhaps the
whole glossary was prefaced with “For a given system:”? And just for kicks, if someone is already within a system, why would they
be a candidate (from the system’s perspective)? Therefore, why isn’t a
‘candidate entity’ an ‘applicant’? Joe posits: Using these terms, we can now say, in a much more understandable way that - *identity verification* is the process of relating attributes to a
known entity (and recording that correlation in a profile)
- *identity proofing* is the process of determining if a candidate
entity is the entity represented by a profile
- *identity assurance* is the documented process assuring that
identity proofing occurred according to policy I don’t find those definitions understandable, from my perspective which
I guess is from an ingrained ISO and NIST perspective: if we refer to SP
800-63 rev.3 there is a clear paradigm, reflected in the Kantara assessment
criteria, that proofing involves evidence selection, validation and
verification. That would knock the implication of the first two terms
above that verification precedes proofing, which frankly I think is putting
the cart before the horse. If an identity was ‘verified’, then wouldn’t it
be proven and no further determination be necessary? Perhaps I’m reading
too much into the definitions and there was never the intention to imply a
sequence, but somehow there surely has to be a relationship between them,
or they fulfil no purpose. Further, assurance is not the process. Assurance is the degree of
trust/confidence one can have that the process was correctly and
competently applied as defined (and that definition has to be before the
one seeking to have that assurance). That is why, within the IAF, we
require CSPs to publish their service definition and policies at least to
the intended user community, which includes those whom rely upon that
assurance. The assurance comes from the published Approval in Kantara’s
TSL, with an understanding of the processes applied by both Kantara and the
CSP in the provision of the Approved service. Nothing solved, sorry. *Richard G. WILSHERFounder & CEO, Zygma Inc.* * [image: Kantara-Accreditedcrop] [image:
cid:image007.jpg@01D1D857.39E3F490] Operating independently since 1993M:
+1 714 797 99 42E:* *RGW@Zygma.biz* *From:* DG-IDPVUseCases [mailto:
dg-idpvusecases-bounces@kantarainitiative.org] *On Behalf Of *Ken Dagg
*Sent:* Wednesday, January 30, 2019 12:20
*To:* Joe Andrieu
*Cc:* dg-idpvusecases@kantarainitiative.org
*Subject:* Re: [DG-IDPVUseCases] Terminology questions Joe, I have been lurking on this discussion group because, other than the
first call, I have been unable to attend the calls dues to conflicts. I understand your confusion around terminology and thank you for your
email trying to clear it up. I think I follow your logic and, to the extent that I do, I like what
you’re saying. I do have the following comment. You identify from ISO 27460-1 “*identity - *set of attributes related
to an entity” Later in your email you propose the following: *profile* - set of attributes in a system related to an known entity *known entity - *an entity with an associated set of attributes in a
system *candidate entity - *an entity who may or may not have a profile in a
system To me the definition of *profile* bears a significant likeness to the
ISO definition of *identity* with the exception that the attributes are
related to a known entity rather than to just an entity (whether known or
unknown). Accepting my premise would change the definitions of the terms you
propose to the following: *profile* - the identity of an known entity *known entity - *an entity with an identity in a system *candidate entity - *an entity who may or may not have a profile in a
system Looking at these new definitions I’d suggest that the term *profile* is,
in essence, redundant to the term *known entity.* If the terms are the same then I’d suggest that the definitions of these
terms become: *known entity - *an entity with an identity in a system *candidate entity - *an entity who may or may not have an *identity* in
a system Similarly, I’d also suggest that the definitions of the following terms
change as well: - *identity verification* is the process of relating attributes to a *known
entity* (and recording that correlation in an *identity*)
- *identity proofing* is the process of determining if a *candidate
entity* is the entity represented by an *identity* (in essence,
changing the status of an entity from unknown to known)
- *identity assurance* is the documented process assuring that
identity proofing occurred according to policy My suggestions are also made with the knowledge that *profile* is an
established term that is already used by Kantara to define the extensions
to a published set of Service Assessment Criteria specified by a federation
to meet its specific requirements. While it is possible to change this term
within the Kantara Identity Assurance Framework, I’d really like to avoid
having to do so. Thoughts, Ken Chair Kantara Initiative Identity Assurance Working Group (IAWG) On Tue, Jan 29, 2019 at 11:06 PM Joe Andrieu On the calls I've mentioned a few times my confusion over some of the
terminology in the referenced ISO docs. On last week's call, at least some
of that was cleared up. This email is an attempt to document my current
understanding and any remaining confusion. At the core of this is the definition of the term identity in ISO
27460-1, as presented in the Notes on ISO Terminology
https://kantarainitiative.org/confluence/display/IDPVUseCases/Notes+on+ISO+t... page,
and its relationship to the replacement rule. *identity* set of attributes related to an entity That same page presents the replacement rule in the following way: ISO definitions use the 'replacement rule' approach - this means that
wherever a defined term appears in text, the reader can directly substitute
the definition and the resulting text shall make sense. Or, in ISO Directives-speak: "The definition shall be written in such a
form that it can replace the term in its context." First, what we cleared up last week was that that when multi-word phrases
are defined explicitly, the individual terms are not themselves subject to
the replacement rule. For example, with regards to the term "identity information" on that same
set of definitions from ISO 27460-1: *identity information* set of values of attributes optionally with any
associated metadata in an identity That initial term does not get replaced, i.e., the following would be
incorrect application of the replacement rule: *set of attributes related to an entity information* set of values of
attributes optionally with any associated metadata in a set of attributes
related to an entity That part helped a LOT. However, that also suggest the correct replacement would be: *identity information* set of values of attributes optionally with any
associated metadata in a *set of attributes related to an entity* Ok. That's awkward, but that's why we have replacement rules, to simplify
awkward phrasing. I suppose this is reasonably restated without substantive
change as *identity information *set of values of attributes (and any associated
metadata) related to an entity I can wrap my head around that with the exception that it seems
absolutely redundant. Since meta-data *are* attributes related to an entity
(albeit with some indirection), both "identity" and "identity information"
are the set of attributes related to an entity. As near as I can read,
there is no functional distinction between the "value of attributes with
any associated meta-data" and the "attributes related to an entity". What
are those attributes if they aren't the value? Since meta-data is data, and
data that ultimately links back to an entity is related to that entity, is
there any distinction here? Ok. So that's one set of confusion. There seems to be no difference
between the meaning of "identity" and "identity information". It's worth
noting that the rest of the terms defined (as from ISO 27460-1) use the
phrase "identity information" which at least has a certain consistency. And
within that set of definitions makes the synonymity a minor issue. The only exception in that glossary is the term "identity register" used
in the definition of "identity registration". That would be replaced as
"set-of-attributes-related-to-an-entity registry", which while awkward, at
least is clear. I added the hyphens to make it clear that the entire
hyphenated phrase is an adjective of registry. There is also a bit of awkwardness in the definition of authentication,
but which I'm ommitting to get to the point that's relevant to our
conversation on identity assurance use cases. Once we get to the definitions for Identity Assurance, I get lost. To wit (from the wiki in the section started by "SC 27/WG 5 describes
Identity Assurance as") : 1.a An identity is established through verification of a set of identity
attributes using acceptable evidence or validated systemically against an
authoritative data source; then Is replaced as A set of attributes related to an entity is established through
verification of a set of identity attributes using acceptable evidence or
validated systemically against an authoritative data source; then This makes sense, but the next does not: This identity is bound to the entity. Gets replaced as This set-of-attributes-related-to-an-entity is bound to the entity. On the surface, this is meaningless to me. I have a conjecture about what
it means, but it depends on some adjustments to the terminology and the
recognition that these two terms "entity" are not the same in an important
way. My attempt at clarifying this also depends on some subtlety that was
suggested on the call last week, but which I did not believe wass
consistent with the definition of identity assurance as presented, but that
problem might be because the term "assured process" is not defined and is
unfamiliar to me. My question to the group was "what are the differences between identity
assurance and identity proofing?" Because the IDPVUseCases wiki page calls
out assurance as distinct from identity proofing and identity verification
but doesn't explain how it differs. I felt confident in my understanding of
verification (as well as how authentication is yet again something
altogether different), but I was struggling to understand the difference
between assurance and proofing. The answer that came out of that conversation is that proofing is the
process by which you discern whether or not the current user *is* the
person you think they are and that assurance is how to prove that the
proofing process occurred as defined. This resonated with the distinctions
I understand from ISO9001 about quality as not just what you measure and
what those measurements should be, but how you document that the
measurements were taken and that they met (or didn't meet) the documented
requirements. If "assured process" maps to this understanding, than I think
I'm on the same page. Aside from the confusing language, I think there is a conflation here
that deserves fixing. To describe it I'm going to use some alternate language, which after
discussion I'm hoping we can map back to standard terms with minimal loss
of meaning and minimal desired changes to those standard terms. *profile* set of attributes in a system related to an known entity *known entity *an entity with an associated set of attributes in a system *candidate entity *an entity who may or may not have a profile in a
system I clarify "in a system" because when you read the non-glossary section
in ISO 27460-1, it's clear that the definition of identity *only* applies
to the attributes related to an entity *within* a given ICT system. I
believe the term *identity* in that specification is better labeled as
"profile" with the inclusion of the scoping to a given system. Using these terms, we can now say, in a much more understandable way that - *identity verification* is the process of relating attributes to a
known entity (and recording that correlation in a profile)
- *identity proofing* is the process of determining if a candidate
entity is the entity represented by a profile
- *identity assurance* is the documented process assuring that
identity proofing occurred according to policy These definitions feel coherent and consistent with what I believe we are
talking about. In particular, the term candidate came from Jack Callahan's
biometrics work where the Candidate Biometric Vector is matched against an
Initial Biometric Vector created at enrollment. His distinction helped me
see the conflation of "entity" that was tripping me up in the replaced
phrase This set-of-attributes-related-to-an-entity is bound to the entity. This would be clearer if the two sentences said 1.a A profile is established through verification of a set of identity
attributes using acceptable evidence or validated systemically against an
authoritative data source; then This profile is bound to the candidate entity. After this step, the candidate entity is now a known entity. I realize we may not have much influence to adjust the terminology
upstream--and that even if this clarification resonates with the people
behind those standards it could take a while to incorporate these comments. HOWEVER, can we clarify for the work we are doing together what is meant
by assurance v proofing v verification? To wit, the use cases I'm sifting through as possible contributions would
need slightly different edits for the notion of assurance I gave above so
I'd like to make sure we're talking about the same thing. -j -- Joe Andrieu, PMP
joe@legreq.com LEGENDARY REQUIREMENTS
+1(805)705-8651 Do what matters.
http://legreq.com
http://www.legendaryrequirements.com _______________________________________________
DG-IDPVUseCases mailing list
DG-IDPVUseCases@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases -- Kenneth Dagg Independent Consultant Identification and Authentication
613-825-2091 kendaggtbs@gmail.com
_______________________________________________
DG-IDPVUseCases mailing list
DG-IDPVUseCases@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases _______________________________________________
DG-IDPVUseCases mailing list
DG-IDPVUseCases@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases