Reminder: IDPV Use Cases DG call 30 January 2019
Yes, there's a call this week, and yes, I will be on it! Apologies for missing the last few calls - thank you to Scott for keeping things moving forward. I have a few more use case drafts to upload tonight andrew. Title: IDPV Use Cases DG IDPV Use Cases DG happens every week on Wednesday.Wednesdays, 60 minutes, on GTM2:11:00 Pacific Time14:00 Eastern Time19:00 UTCTime zone converter: www.thetimenow.com/time-zone-converter.php Dial In Credentials Below:https://global.gotomeeting.com/join/320496725 You can also dial in using your phone. United States: +1 (786) 535-3119 Access Code: 320-496-725 More phone numbers Australia: +61 2 8355 1038 Austria: +43 7 2081 5337 Belgium: +32 28 93 7002 Canada: +1 (647) 497-9373 Denmark: +45 32 72 03 69 Finland: +358 942 72 0972 France: +33 170 950 590 Germany: +49 692 5736 7300 Ireland: +353 15 360 756 Italy: +39 0 230 57 81 80 Netherlands: +31 207 941 375 New Zealand: +64 9 913 2226 Norway: +47 21 93 37 37 Spain: +34 932 75 1230 Sweden: +46 853 527 818 Switzerland: +41 225 4599 60 United Kingdom: +44 330 221 0097 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check When: Wed Jan 30, 2019 11:00 – 12:00 Pacific Time - Vancouver Where: GoToMeeting (GTM2) Who: * Andrew Hughes - organizer
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/>
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 <joe@legreq.com> wrote:
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
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. WILSHER Founder & CEO, Zygma Inc. Kantara-Accreditedcrop cid:image007.jpg@01D1D857.39E3F490 Operating independently since 1993 M: +1 714 797 99 42 E: <mailto:RGW@Zygma.biz> RGW@Zygma.biz W: <http://www.zygma.biz/> www.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 <joe@legreq.com> wrote: 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
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* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <http://www.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 <joe@legreq.com> wrote:
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
Sorry I missed the call tonight, will pick up on Friday. Regards Stuart On Wed, 30 Jan 2019, 19:01 John Callahan <jcallahan@veridiumid.com wrote:
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* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <http://www.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 <joe@legreq.com> wrote:
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
I struggle with “assurance is a documented process assuring…”. PS – may be unable to join … client call Richard G. WILSHER Founder & CEO, Zygma Inc. cid:1689faf96411f3aa072 cid:image007.jpg@01D1D857.39E3F490 Operating independently since 1993 M: +1 714 797 99 42 E: <mailto:RGW@Zygma.biz> RGW@Zygma.biz W: <http://www.zygma.biz/> www.Zygma.biz From: John Callahan [mailto:jcallahan@veridiumid.com] Sent: Wednesday, January 30, 2019 19:01 To: Richard G. WILSHER (@Zygma) Cc: dg-idpvusecases@kantarainitiative.org Subject: Re: [DG-IDPVUseCases] Terminology questions 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 <http://www.veridiumid.com> Veridium 1177 Avenue of the Americas | 5th Floor New York, NY 10036 | USA <https://www.linkedin.com/company/veridium> LinkedIn <https://twitter.com/veridiumid> Twitter <https://facebook.com/veridiumid> Facebook 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. WILSHER Founder & CEO, Zygma Inc. Kantara-Accreditedcrop cid:image007.jpg@01D1D857.39E3F490 Operating independently since 1993 M: +1 714 797 99 42 E: <mailto:RGW@Zygma.biz> RGW@Zygma.biz W: <http://www.zygma.biz/> www.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 <joe@legreq.com> wrote: 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
+1 to John's remark on Richard's comment. We could borrow a term from Common Criteria and say that *evaluation* is the name of the process that results in assurance. Then it becomes a combination of what combination of self-assessment and third-party evaluation, achieves the amount of assurance required. On Wed, Jan 30, 2019 at 2:01 PM John Callahan <jcallahan@veridiumid.com> wrote:
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* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <http://www.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 <joe@legreq.com> wrote:
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
Hi, I apologize for not being able to join calls. In ARIES project (https://www.aries-project.eu/) we had similar discussion with Idemia and Gemalto representatives. Idemia was claiming that the UK government, in its GPG 45 (Good Pratice Guide about Identity Proofing and Verification) defines global process as the identity proofing that is supported by various unique claims (document, biometrics …) verifications (https://www.ncsc.gov.uk/content/files/guidance_files/GPG%2045%20%20-%20valid...). However, I found a counterargument in definition from Secure Technology Alliance (where both Idemia and Gemalto have a leading role). Definition there suggest something almost opposite: proofing as one step within identity verification (https://www.securetechalliance.org/wp-content/uploads/Mobile-Identity-Authen...). I guess we will have to cope with this all the time, so maybe it is wise to compile references to different documents and definitions. Best regards Aljosa From: DG-IDPVUseCases <dg-idpvusecases-bounces@kantarainitiative.org> On Behalf Of Richard G. WILSHER (@Zygma) Sent: Wednesday, January 30, 2019 5:21 PM To: dg-idpvusecases@kantarainitiative.org Subject: Re: [DG-IDPVUseCases] Terminology questions 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. WILSHER Founder & CEO, Zygma Inc. [cid:image001.jpg@01D4B94C.4B0A8260] [Kantara-Accreditedcrop] [cid:image007.jpg@01D1D857.39E3F490] [cid:image004.jpg@01D4B94C.4B0A8260] Operating independently since 1993 M: +1 714 797 99 42 E: RGW@Zygma.biz<mailto:RGW@Zygma.biz> W: www.Zygma.biz<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zygma.biz%2F&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902865979&sdata=OEft1ZnjnFBF01PPTMlpPrrv%2FUgFqOQ%2FQWDKbNYdh6w%3D&reserved=0> 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<mailto: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 <joe@legreq.com<mailto:joe@legreq.com>> wrote: 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+terminology<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fconfluence%2Fdisplay%2FIDPVUseCases%2FNotes%2Bon%2BISO%2Bterminology&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=l1BZ%2BONk8SHmNPTtD3%2FSQTv0afXaW9tUZjvi7zNCsHI%3D&reserved=0> 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<mailto:joe@legreq.com> LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=jmRew2OTD4muiB4yN%2Bl0HvtG3H2Tr9LFpTSxMQbDMuI%3D&reserved=0> _______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org<mailto:DG-IDPVUseCases@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fmailman%2Flistinfo%2Fdg-idpvusecases&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902885993&sdata=puou7OzI03KbDfLDElxb9tS%2Fsiu9CKqFVeOiN%2BVG9AQ%3D&reserved=0> -- Kenneth Dagg Independent Consultant Identification and Authentication 613-825-2091 kendaggtbs@gmail.com<mailto:kendaggtbs@gmail.com> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener información confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente y pueden estar protegidos por secreto profesional. Si usted recibe este correo electrónico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningún compromiso para el grupo Atos, salvo ratificación escrita por ambas partes. Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no será responsable de cualesquiera daños que puedan resultar de una transmisión de virus.
Ah-ha! Thank you for those links Aljosa - I'll review them. To me, proofing is about confirming that the documented identification presented by the person matches the documented identification held at the issuer/authority. Identity verification goes beyond that and does not necessarily need to verify 'legal name' and other documented/assigned identifiers. The purpose of proofing: to confirm that documents issued in the past to *AN* individual were issued to *THE* individual making the claim today. The purpose of verification: to resolve/determine/uniquely identify/disambiguate the entity making any identifier claim that pertains to themselves as the subject. The overarching outcome of either is to establish identifiers (bound to credentials) that can be used in the future as the basis of authentication of the 'returning' entity. *Andrew Hughes *CISM CISSP *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com *https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>* *Digital Identity | International Standards | Information Security * On Thu, Jan 31, 2019 at 1:04 AM Pasic, Aljosa <aljosa.pasic@atos.net> wrote:
Hi,
I apologize for not being able to join calls.
In ARIES project (https://www.aries-project.eu/) we had similar discussion with Idemia and Gemalto representatives.
Idemia was claiming that the UK government, in its GPG 45 (Good Pratice Guide about Identity Proofing and Verification) defines global process as the identity proofing that is supported by various unique claims (document, biometrics …) verifications ( https://www.ncsc.gov.uk/content/files/guidance_files/GPG%2045%20%20-%20valid...). However, I found a counterargument in definition from Secure Technology Alliance (where both Idemia and Gemalto have a leading role). Definition there suggest something almost opposite: proofing as one step within identity verification ( https://www.securetechalliance.org/wp-content/uploads/Mobile-Identity-Authen... ).
I guess we will have to cope with this all the time, so maybe it is wise to compile references to different documents and definitions.
Best regards
Aljosa
*From:* DG-IDPVUseCases <dg-idpvusecases-bounces@kantarainitiative.org> *On Behalf Of *Richard G. WILSHER (@Zygma) *Sent:* Wednesday, January 30, 2019 5:21 PM *To:* dg-idpvusecases@kantarainitiative.org *Subject:* Re: [DG-IDPVUseCases] Terminology questions
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. WILSHER Founder & CEO, Zygma Inc. [image: Kantara-Accreditedcrop] [image: cid:image007.jpg@01D1D857.39E3F490] Operating independently since 1993 M: +1 714 797 99 42 E:* *RGW@Zygma.biz* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zygma.biz%2F&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902865979&sdata=OEft1ZnjnFBF01PPTMlpPrrv%2FUgFqOQ%2FQWDKbNYdh6w%3D&reserved=0>
*From:* DG-IDPVUseCases [ mailto:dg-idpvusecases-bounces@kantarainitiative.org <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 <joe@legreq.com> wrote:
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... <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fconfluence%2Fdisplay%2FIDPVUseCases%2FNotes%2Bon%2BISO%2Bterminology&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=l1BZ%2BONk8SHmNPTtD3%2FSQTv0afXaW9tUZjvi7zNCsHI%3D&reserved=0> 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 <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=jmRew2OTD4muiB4yN%2Bl0HvtG3H2Tr9LFpTSxMQbDMuI%3D&reserved=0>
_______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fmailman%2Flistinfo%2Fdg-idpvusecases&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902885993&sdata=puou7OzI03KbDfLDElxb9tS%2Fsiu9CKqFVeOiN%2BVG9AQ%3D&reserved=0>
--
Kenneth Dagg Independent Consultant Identification and Authentication 613-825-2091 kendaggtbs@gmail.com This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Este mensaje y los ficheros adjuntos pueden contener información confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente y pueden estar protegidos por secreto profesional. Si usted recibe este correo electrónico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningún compromiso para el grupo Atos, salvo ratificación escrita por ambas partes. Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no será responsable de cualesquiera daños que puedan resultar de una transmisión de virus. _______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases
Clarification requested… The purpose of proofing: to confirm that documents issued in the past to AN individual were issued to THE individual making the claim today. The purpose of verification: to resolve/determine/uniquely identify/disambiguate the entity making any identifier claim that pertains to themselves as the subject. The overarching outcome of either is to establish identifiers (bound to credentials) that can be used in the future as the basis of authentication of the 'returning' entity. Is the entity making an identifier claim (which implies an established identifier) or is the entity establishing an identifier? Or do you mean something different? From: DG-IDPVUseCases [mailto:dg-idpvusecases-bounces@kantarainitiative.org] On Behalf Of Andrew Hughes Sent: Thursday, January 31, 2019 9:41 AM To: Pasic, Aljosa <aljosa.pasic@atos.net> Cc: dg-idpvusecases@kantarainitiative.org Subject: [EXTERNAL] Re: [DG-IDPVUseCases] Terminology questions Ah-ha! Thank you for those links Aljosa - I'll review them. To me, proofing is about confirming that the documented identification presented by the person matches the documented identification held at the issuer/authority. Identity verification goes beyond that and does not necessarily need to verify 'legal name' and other documented/assigned identifiers. The purpose of proofing: to confirm that documents issued in the past to AN individual were issued to THE individual making the claim today. The purpose of verification: to resolve/determine/uniquely identify/disambiguate the entity making any identifier claim that pertains to themselves as the subject. The overarching outcome of either is to establish identifiers (bound to credentials) that can be used in the future as the basis of authentication of the 'returning' entity. Andrew Hughes CISM CISSP In Turn Information Management Consulting o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com<mailto:AndrewHughes3000@gmail.com> https://www.linkedin.com/in/andrew-hughes-682058a Digital Identity | International Standards | Information Security On Thu, Jan 31, 2019 at 1:04 AM Pasic, Aljosa <aljosa.pasic@atos.net<mailto:aljosa.pasic@atos.net>> wrote: Hi, I apologize for not being able to join calls. In ARIES project (https://www.aries-project.eu/) we had similar discussion with Idemia and Gemalto representatives. Idemia was claiming that the UK government, in its GPG 45 (Good Pratice Guide about Identity Proofing and Verification) defines global process as the identity proofing that is supported by various unique claims (document, biometrics …) verifications (https://www.ncsc.gov.uk/content/files/guidance_files/GPG%2045%20%20-%20valid...). However, I found a counterargument in definition from Secure Technology Alliance (where both Idemia and Gemalto have a leading role). Definition there suggest something almost opposite: proofing as one step within identity verification (https://www.securetechalliance.org/wp-content/uploads/Mobile-Identity-Authen...). I guess we will have to cope with this all the time, so maybe it is wise to compile references to different documents and definitions. Best regards Aljosa From: DG-IDPVUseCases <dg-idpvusecases-bounces@kantarainitiative.org<mailto:dg-idpvusecases-bounces@kantarainitiative.org>> On Behalf Of Richard G. WILSHER (@Zygma) Sent: Wednesday, January 30, 2019 5:21 PM To: dg-idpvusecases@kantarainitiative.org<mailto:dg-idpvusecases@kantarainitiative.org> Subject: Re: [DG-IDPVUseCases] Terminology questions 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. WILSHER Founder & CEO, Zygma Inc. [cid:image001.jpg@01D4B955.8C4AFB70] [Kantara-Accreditedcrop] [cid:image007.jpg@01D1D857.39E3F490] [cid:image004.jpg@01D4B955.8C4AFB70] Operating independently since 1993 M: +1 714 797 99 42 E: RGW@Zygma.biz<mailto:RGW@Zygma.biz> W: www.Zygma.biz<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zygma.biz%2F&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902865979&sdata=OEft1ZnjnFBF01PPTMlpPrrv%2FUgFqOQ%2FQWDKbNYdh6w%3D&reserved=0> 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<mailto: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 <joe@legreq.com<mailto:joe@legreq.com>> wrote: 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+terminology<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fconfluence%2Fdisplay%2FIDPVUseCases%2FNotes%2Bon%2BISO%2Bterminology&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=l1BZ%2BONk8SHmNPTtD3%2FSQTv0afXaW9tUZjvi7zNCsHI%3D&reserved=0> 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<mailto:joe@legreq.com> LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=jmRew2OTD4muiB4yN%2Bl0HvtG3H2Tr9LFpTSxMQbDMuI%3D&reserved=0> _______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org<mailto:DG-IDPVUseCases@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fmailman%2Flistinfo%2Fdg-idpvusecases&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902885993&sdata=puou7OzI03KbDfLDElxb9tS%2Fsiu9CKqFVeOiN%2BVG9AQ%3D&reserved=0> -- Kenneth Dagg Independent Consultant Identification and Authentication 613-825-2091 kendaggtbs@gmail.com<mailto:kendaggtbs@gmail.com> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener información confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente y pueden estar protegidos por secreto profesional. Si usted recibe este correo electrónico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningún compromiso para el grupo Atos, salvo ratificación escrita por ambas partes. Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no será responsable de cualesquiera daños que puedan resultar de una transmisión de virus. _______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org<mailto:DG-IDPVUseCases@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases
Recursion is a pain, eh? In my head, all of this proofing and verification is about confirming that **some other organization** has encountered and has a record of the entity being proofed/verified today. Sure, there may be some identifiers on the verification side of the fence that have never been recorded by another organization. But for Proofing, it is always about looking into the past for a match of some sort. It's the corroboration of attributes values and reducing the likelihood of identification collisions (e.g. false positive matches) that form the basis of the procedures used in ID Proofing. The proofer/verifier is contributing towards enrolment (identification of the unique entity in the context/domain) and registration (recording details about that entity in a registry) - the act of registration (in a database of some kind) necessarily causes the creation of a new identifier (minimally the database index) and maybe other more friendly identifiers like a document serial number. It's the latter identifiers that are established so that the entity can be recognized when they return and are checked against the newly-created registry record. Does this mesh with your conceptualization? *Andrew Hughes *CISM CISSP *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com *https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>* *Digital Identity | International Standards | Information Security * On Thu, Jan 31, 2019 at 8:10 AM Mcbride, Terence W - Washington, DC - Contractor <Terence.W.Mcbride@usps.gov> wrote:
Clarification requested…
The purpose of proofing: to confirm that documents issued in the past to *AN* individual were issued to *THE* individual making the claim today.
The purpose of verification: to resolve/determine/uniquely identify/disambiguate the entity making any identifier claim that pertains to themselves as the subject.
The overarching outcome of either is to establish identifiers (bound to credentials) that can be used in the future as the basis of authentication of the 'returning' entity.
Is the entity making an identifier claim (which implies an established identifier) or is the entity establishing an identifier? Or do you mean something different?
*From:* DG-IDPVUseCases [mailto: dg-idpvusecases-bounces@kantarainitiative.org] *On Behalf Of *Andrew Hughes *Sent:* Thursday, January 31, 2019 9:41 AM *To:* Pasic, Aljosa <aljosa.pasic@atos.net> *Cc:* dg-idpvusecases@kantarainitiative.org *Subject:* [EXTERNAL] Re: [DG-IDPVUseCases] Terminology questions
Ah-ha!
Thank you for those links Aljosa - I'll review them.
To me, proofing is about confirming that the documented identification presented by the person matches the documented identification held at the issuer/authority.
Identity verification goes beyond that and does not necessarily need to verify 'legal name' and other documented/assigned identifiers.
The purpose of proofing: to confirm that documents issued in the past to *AN* individual were issued to *THE* individual making the claim today.
The purpose of verification: to resolve/determine/uniquely identify/disambiguate the entity making any identifier claim that pertains to themselves as the subject.
The overarching outcome of either is to establish identifiers (bound to credentials) that can be used in the future as the basis of authentication of the 'returning' entity.
*Andrew Hughes *CISM CISSP *In Turn Information Management Consulting*
o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com *https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>* *Digital Identity | International Standards | Information Security *
On Thu, Jan 31, 2019 at 1:04 AM Pasic, Aljosa <aljosa.pasic@atos.net> wrote:
Hi,
I apologize for not being able to join calls.
In ARIES project (https://www.aries-project.eu/) we had similar discussion with Idemia and Gemalto representatives.
Idemia was claiming that the UK government, in its GPG 45 (Good Pratice Guide about Identity Proofing and Verification) defines global process as the identity proofing that is supported by various unique claims (document, biometrics …) verifications ( https://www.ncsc.gov.uk/content/files/guidance_files/GPG%2045%20%20-%20valid...). However, I found a counterargument in definition from Secure Technology Alliance (where both Idemia and Gemalto have a leading role). Definition there suggest something almost opposite: proofing as one step within identity verification ( https://www.securetechalliance.org/wp-content/uploads/Mobile-Identity-Authen... ).
I guess we will have to cope with this all the time, so maybe it is wise to compile references to different documents and definitions.
Best regards
Aljosa
*From:* DG-IDPVUseCases <dg-idpvusecases-bounces@kantarainitiative.org> *On Behalf Of *Richard G. WILSHER (@Zygma) *Sent:* Wednesday, January 30, 2019 5:21 PM *To:* dg-idpvusecases@kantarainitiative.org *Subject:* Re: [DG-IDPVUseCases] Terminology questions
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. WILSHER Founder & CEO, Zygma Inc. [image: Kantara-Accreditedcrop] [image: cid:image007.jpg@01D1D857.39E3F490] Operating independently since 1993 M: +1 714 797 99 42 E:* *RGW@Zygma.biz* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zygma.biz%2F&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902865979&sdata=OEft1ZnjnFBF01PPTMlpPrrv%2FUgFqOQ%2FQWDKbNYdh6w%3D&reserved=0>
*From:* DG-IDPVUseCases [ mailto:dg-idpvusecases-bounces@kantarainitiative.org <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 <joe@legreq.com> wrote:
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... <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fconfluence%2Fdisplay%2FIDPVUseCases%2FNotes%2Bon%2BISO%2Bterminology&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=l1BZ%2BONk8SHmNPTtD3%2FSQTv0afXaW9tUZjvi7zNCsHI%3D&reserved=0> 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 <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902875988&sdata=jmRew2OTD4muiB4yN%2Bl0HvtG3H2Tr9LFpTSxMQbDMuI%3D&reserved=0>
_______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkantarainitiative.org%2Fmailman%2Flistinfo%2Fdg-idpvusecases&data=02%7C01%7Caljosa.pasic%40atos.net%7C85504c303b3844ca865108d686cefca8%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C636844620902885993&sdata=puou7OzI03KbDfLDElxb9tS%2Fsiu9CKqFVeOiN%2BVG9AQ%3D&reserved=0>
--
Kenneth Dagg Independent Consultant Identification and Authentication 613-825-2091 kendaggtbs@gmail.com
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Este mensaje y los ficheros adjuntos pueden contener información confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente y pueden estar protegidos por secreto profesional. Si usted recibe este correo electrónico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningún compromiso para el grupo Atos, salvo ratificación escrita por ambas partes. Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no será responsable de cualesquiera daños que puedan resultar de una transmisión de virus.
_______________________________________________ DG-IDPVUseCases mailing list DG-IDPVUseCases@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idpvusecases
I think we're seeing a basic fact is that the substitution rule is not something that these glossaries have been validated against, so applying it now is revealing inconsistencies. But let's keep in mind the context of the rule - it was very much with widgets in mind: 2.1.17die<extrusion> metal block with a shaped orifice through which plastic material is extruded When the terms being defined are abstractions like "identity" or processes like "verification", "proofing", "authentication", it gets a bit more challenging, but I think that the effort would be worthwhile. 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* <RGW@Zygma.biz> *W:* *www.Zygma.biz* <http://www.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 <joe@legreq.com> wrote:
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
I won't be able to make the call at 2pm EDT today (in the air) but on schedule for Fri delivery of 3 use cases (Aadhaar India, RENIAC Peru, and INE Mexico) On Tue, Jan 29, 2019, 23:06 Joe Andrieu <joe@legreq.com wrote:
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
participants (9)
-
Andrew Hughes
-
Joe Andrieu
-
John Callahan
-
Ken Dagg
-
Mcbride, Terence W - Washington, DC - Contractor
-
Pasic, Aljosa
-
Richard G. WILSHER (@Zygma)
-
Scott Shorter
-
Stuart Young