Subject: [VoT] How to express duplicate checks with VoT?

From: Rolf Brugger <[email-masked]>
Date: Thu, 10 Mar 2016 17:51:04 +0100

Hi all,

I'm new to this list and I hope my question is not totally irrelevant here.

We have plenty of use cases where RPs need to have confidence, that a 
person does not have multiple identities in one IdP. I don't see how 
this aspect of identity quality can be expressed, and I believe it is 
pretty orthogonal to the P, C, M and A dimensions that are currently 
specified in the VoT draft.

We could imagine multiple ways to gradually prove that an identity has 
been checked against duplicates. The most straightforward approach would 
be to make sure that unique personal attributes are used only once 
within one IdP or an IdP federation, like
- email address(es)
- mobile phone number
- home postal address
- social security number
- ID / passport number
- the combination of name and birth date
- etc.

Would it make sense to express this in VoT?

best regards

Rolf

-- 
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 15 89
[email-masked], http://www.switch.ch

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Mar 2016 13:57:44 -0500

This would probably be another category/dimension, I think. Unless you wanted to wrap it into your own definitions of the “P” dimension, where there’d be a “Pu” for “proofed unique” that could be added to that category. 

 — Justin

> On Mar 10, 2016, at 11:51 AM, Rolf Brugger <[email-masked]> wrote:
> 
> Hi all,
> 
> We have plenty of use cases where RPs need to have confidence, that a person does not have multiple identities in one IdP. I don't see how this aspect of identity quality can be expressed, and I believe it is pretty orthogonal to the P, C, M and A dimensions that are currently specified in the VoT draft.
> 
> We could imagine multiple ways to gradually prove that an identity has been checked against duplicates. The most straightforward approach would be to make sure that unique personal attributes are used only once within one IdP or an IdP federation, like
> - email address(es)
> - mobile phone number
> - home postal address
> - social security number
> - ID / passport number
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot

---

From: Eric Goodman <[email-masked]>
Date: Thu, 10 Mar 2016 19:27:39 +0000

This seems like it would be really hard to specify, unless you scope it pretty clearly.

"Proofed unique among accounts with identity vetting level (moderate or higher)" seems like it might be achievable (and maybe is what you have in mind). "Proofed unique" literally seems nearly impossible. How would you prove someone didn't get a low-value account on the same IdP? 

The challenge to me would be defining the scope in a way that is understandable and agreeable.

--- Eric

-----Original Message-----
From: vot [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, March 10, 2016 10:58 AM
To: Rolf Brugger
Cc: [email-masked]
Subject: Re: [VoT] How to express duplicate checks with VoT?

 — Justin

> been checked against duplicates. The most straightforward approach 
> would be to make sure that unique personal attributes are used only 
> once within one IdP or an IdP federation, like
> - email address(es)
> - mobile phone number
> - home postal address
> - social security number
> - ID / passport number
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 
> 15, direct +41 44 268 15 89 [email-masked], 
> http://www.switch.ch
>

---

From: Joanne Knight <[email-masked]>
Date: Fri, 11 Mar 2016 01:56:54 +0000

Hi All

There are three aspect or levels when looking at uniqueness to be considered.

First level is that the identity is unique - that is, within a context there is a set of attributes that are unique for each identity registered.

Second level is sole claimant - this is a check that only one entity has claimed a particular set of attributes. At the higher levels of identity proofing where authoritative sources are used it may be possible to achieve this. This is sufficient in most RPs cases. At this level while it is possible for a single entity to claim more than one identity, they do so at the risk of causing a counter-fraud flag should the real owner (or any other party) also attempt to claim the identity.

The final level is one and only one - This is a check - usually biometric - that an entity has only one claim in the context. This is usually only reserved for the highest level of identity and would also require equally high levels of credential and credential issuance processes.

As to how this relates to VoT - 
The first should be innately built into all levels of P - it is the sole requirement of all levels

The second could be built into P3 if the wording was amended slightly.

The last item only is substantively missing and to date (in the conversations I have been having elsewhere) there has been insufficient appetite to add it as an explicit requirement. 

Should we have a PU? Maybe, but steer clear of the term 'unique'
If we do, in my mind it would only have two values - P?0 - Claims per entity not checked, P?1 - Claims per entity restricted to one.

Joanne

-----Original Message-----
From: Rolf Brugger [mailto:[email-masked]] 
Sent: Friday, 11 March 2016 5:51 a.m.
To: [email-masked]
Subject: [VoT] How to express duplicate checks with VoT?

Hi all,

best regards

Rolf

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 89 [email-masked], http://www.switch.ch

---

From: Nick Roy <[email-masked]>
Date: Fri, 11 Mar 2016 18:46:07 +0000

Rolf, are your RPs use cases ever approaching the last level that Joanne mentions below?  Hopefully not...

Nick

---

From: Rolf Brugger <[email-masked]>
Date: Thu, 17 Mar 2016 11:34:45 +0100

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs 
in our project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three 
levels of uniqueness described by Joanne. In each of the three levels a 
set of attributes is used to determine if an identity is unique within a 
population of identities. The difference is 1) what exact set of 
attributes is used in each level and 2) the vetting level of the 
attributes. Right?

A concrete example might be

First level:
- attributes: Name, email, phone number
- vetting level: P1

Second level:
- attributes: Name, email, phone number, social security number
- vetting level: P2

Third level:
- attributes: finger print or retina scan
- vetting level: P3

The appropriate set of attributes to be used in each level is certainly 
context-specific. As Eric points out it will be difficult to define and 
agree on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we 
are planning individuals self-register their identities. With such an 
identity, individuals can register for studies at a university. But one 
individual may only register once at the same university. Another case 
is a user's library account that was blocked because of violations of 
the library's usage terms. Such a user should not be able to just create 
a new account to use the library services again.

With Justin's suggestion of a Pu category, the requirements in our use 
cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" 
would then be: Proofed unique based on an attribute set with the vetting 
level P2.

cheers

Rolf

On 11.03.16 02:56, Joanne Knight wrote:
> First level is that the identity is unique - that is, within a
> context there is a set of attributes that are unique for each
> identity registered.
>
> Second level is sole claimant - this is a check that only one entity
> has claimed a particular set of attributes. At the higher levels of
> identity proofing where authoritative sources are used it may be
> possible to achieve this. This is sufficient in most RPs cases. At
> this level while it is possible for a single entity to claim more
> than one identity, they do so at the risk of causing a counter-fraud
> flag should the real owner (or any other party) also attempt to claim
> the identity.
>
> The final level is one and only one - This is a check - usually
> biometric - that an entity has only one claim in the context. This is
> usually only reserved for the highest level of identity and would
> also require equally high levels of credential and credential
> issuance processes.
>
> As to how this relates to VoT - The first should be innately built
> into all levels of P - it is the sole requirement of all levels
>
> The last item only is substantively missing and to date (in the
> conversations I have been having elsewhere) there has been
> insufficient appetite to add it as an explicit requirement.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique' If
> we do, in my mind it would only have two values - P?0 - Claims per
> entity not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> -----Original Message----- From: Rolf Brugger
> [mailto:[email-masked]] Sent: Friday, 11 March 2016 5:51
> a.m. To: [email-masked] Subject: [VoT] How to express duplicate checks
> with VoT?
>
> Hi all,
>
> We could imagine multiple ways to gradually prove that an identity
> has been checked against duplicates. The most straightforward
> approach would be to make sure that unique personal attributes are
> used only once within one IdP or an IdP federation, like - email
> address(es) - mobile phone number - home postal address - social
> security number - ID / passport number - the combination of name and
> birth date - etc.
>
> -- SWITCH -------------------------- Rolf Brugger, project Swiss
> edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44
> 268 15 15, direct +41 44 268 15 89 [email-masked],
> http://www.switch.ch
>
>
> _______________________________________________ vot mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/vot
>

---

From: Joanne Knight <[email-masked]>
Date: Thu, 17 Mar 2016 21:49:20 +0000

The short answer to your question - No.

Your use case is silent on the level of vetting required (how real does the identity have to be). You can have any level of identity and still collect a biometric for the purposes of one and only one uniqueness. I would pose however that it is very unusual for one and only one assurance to be required without some other driver requiring an elevated level of realness. 

In your use case I would suggest that there is also a requirement that a qualification is issued to 
a) the person carrying out the study and 
b) an identity of such rigour that their (or the university's) eligibility for public funding can be established and 
c) an identity that is going to be tested by future employers.

Therefore you are probably looking at P2 or P3 depending on the level/type of qualification. (I might want P3 if the qualification is for brain surgeon or commercial pilot).

As one and only one is really only able to be achieved through the use of a biometric, we now have to consider 'acceptability'.
Does the collection of a biometric (and all that it entails - cost, privacy, security, user acceptance etc.) outweigh the impact caused by a duplicate entity in the system?
In other words, do you really need one and only one (the 3rd level of uniqueness) or could sufficient singularity be gained from leveraging the social security number's uniqueness and an equivalent level of validation and ownership test (the 2nd level of uniqueness) i.e. no Pu?

We must remember the mutual exclusivity between attributes collected, vetting under taken and level of uniqueness. 

Happy to discuss further if this makes no sense.

Cheers

-----Original Message-----
From: Rolf Brugger [mailto:[email-masked]] 
Sent: Thursday, 17 March 2016 11:35 p.m.
To: [email-masked]
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs in our project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three levels of uniqueness described by Joanne. In each of the three levels a set of attributes is used to determine if an identity is unique within a population of identities. The difference is 1) what exact set of attributes is used in each level and 2) the vetting level of the attributes. Right?

First level:

Second level:

Third level:

The appropriate set of attributes to be used in each level is certainly context-specific. As Eric points out it will be difficult to define and agree on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we are planning individuals self-register their identities. With such an identity, individuals can register for studies at a university. But one individual may only register once at the same university. Another case is a user's library account that was blocked because of violations of the library's usage terms. Such a user should not be able to just create a new account to use the library services again.

With Justin's suggestion of a Pu category, the requirements in our use cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" 
would then be: Proofed unique based on an attribute set with the vetting level P2.

cheers

Rolf

On 11.03.16 02:56, Joanne Knight wrote:
> First level is that the identity is unique - that is, within a context 
> there is a set of attributes that are unique for each identity 
> registered.
>
> this level while it is possible for a single entity to claim more than 
> one identity, they do so at the risk of causing a counter-fraud flag 
> should the real owner (or any other party) also attempt to claim the 
> identity.
>
> usually only reserved for the highest level of identity and would also 
> require equally high levels of credential and credential issuance 
> processes.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique' If we 
> do, in my mind it would only have two values - P?0 - Claims per entity 
> not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> [mailto:[email-masked]] Sent: Friday, 11 March 2016 5:51 a.m. 
> To: [email-masked] Subject: [VoT] How to express duplicate checks with 
> VoT?
>
> Hi all,
>
> once within one IdP or an IdP federation, like - email

---

From: Julian White <[email-masked]>
Date: Fri, 18 Mar 2016 13:19:23 +0000

I would say, as I have in the ISO 29003 discussions, that uniqueness is in
fact irrelevant in terms of the level of proofing. I see no need to know
whether that set of attributes is proven to be unique by the proofing
provider. Uniqueness is highly dependent on the context, which raises all
sorts of problems if you have an identity federation (how do I know its
unique across the federation? If, as an RP, I can can cope with
non-uniqueness across the federation then non-uniqueness within the
proofing provider is also not a problem).

In my view it is for the RP, or identity federation scheme, to decide which
attributes are required in their context. They select sufficient attributes
that give them uniqueness (in their context) if that is required, e.g. SSN
for some services (though I would advise against it!). The purpose of the
proofing process is to express to what level of confidence that those
attributes are true and belong to the person presenting them, be they name,
address, dob, email address, SSN etc.

In my dealings with RPs they are confused about this and ask for
"uniqueness", this is usually followed up with "because we can't let people
register multiple identities". There is a lack of understanding that,
assuming the proofing process is working correctly, it doesn't matter how
many times you enrol you are proven to be the same person each time; i.e.
multiple enrolments lead to the identification of the same person being
bound to the same attributes. Therefore it isn't actually a problem in
terms of uniqueness.

More often than not the ask for uniqueness is really an expression of how
well the system defends itself against impostors (different people
registering for the same attributes) which is actually the point of the
different levels of proofing (the higher the levels of proofing the harder
this should become). Demanding uniqueness doesn't actually fix the impostor
problem, you just introduce a time trial to the process; the first person
to get bound to those attributes locks out other people; if the first
person to claim them was the impostor you've now locked out the genuine
person - they now have a hell of time unpicking a mess not of their making.
If the system defends against impostors properly at the higher levels then
the uniqueness adds little value since I can only bind those attributes to
the correct person anyway.

The thing that may need to be unique is the account/record at the RP, and
its the RP's responsibility to manage that. This is a problem they have
regardless of whether the proofing provider tells them its unique or not
because they often have multiple on-line and offline channels that deal
with their customers, this forces them to understand how to match different
representations of the identity to the same account which tends to work
across channel and within the same channel.

So in summary it doesn't drive any real value in the proofing provider to
do this, its just a cost of effort for little gain that the RP is going to
repeat regardless if they care about uniqueness.

Regards,

Julian.

On 17 March 2016 at 21:49, Joanne Knight <[email-masked]> wrote:

> Your use case is silent on the level of vetting required (how real does
> the identity have to be). You can have any level of identity and still
> collect a biometric for the purposes of one and only one uniqueness. I
> would pose however that it is very unusual for one and only one assurance
> to be required without some other driver requiring an elevated level of
> realness.
>
> b) an identity of such rigour that their (or the university's) eligibility
> for public funding can be established and
> Therefore you are probably looking at P2 or P3 depending on the level/type
> of qualification. (I might want P3 if the qualification is for brain
> surgeon or commercial pilot).
>
> As one and only one is really only able to be achieved through the use of
> a biometric, we now have to consider 'acceptability'.
> Does the collection of a biometric (and all that it entails - cost,
> privacy, security, user acceptance etc.) outweigh the impact caused by a
> duplicate entity in the system?
> In other words, do you really need one and only one (the 3rd level of
> uniqueness) or could sufficient singularity be gained from leveraging the
> social security number's uniqueness and an equivalent level of validation
> and ownership test (the 2nd level of uniqueness) i.e. no Pu?
>
> We must remember the mutual exclusivity between attributes collected,
> vetting under taken and level of uniqueness.
>
> Thanks for all your responses and ideas. We have discussed your inputs in
> our project team (which is why it took me some time to respond)
>
> I was wondering what actually the differences are between the three levels
> of uniqueness described by Joanne. In each of the three levels a set of
> attributes is used to determine if an identity is unique within a
> population of identities. The difference is 1) what exact set of attributes
> is used in each level and 2) the vetting level of the attributes. Right?
>
> Maybe it's time to describe our use cases here. In the IdM service we are
> planning individuals self-register their identities. With such an identity,
> individuals can register for studies at a university. But one individual
> may only register once at the same university. Another case is a user's
> library account that was blocked because of violations of the library's
> usage terms. Such a user should not be able to just create a new account to
> use the library services again.
>
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15,
> direct +41 44 268 15 89 [email-masked], http://www.switch.ch
>
>

---

From: Ken Dagg <[email-masked]>
Date: Fri, 18 Mar 2016 13:38:51 -0400

Here, here!!!

I have been a lurker on this group for a while but felt compelled to add my
to cents to this discussion as it is, I believe, an important point to
scoping the discussion as it proceeds.

I agree fully that determining the uniqueness of a subject is totally the
responsibility of the RP. It is their service delivery and they have to
determine what they require in order for them to be assured that they are
dealing with a unique subject. I use subject in order to include the IOT in
the possible solution. If I'm reading what you say correctly, one of the
considerations that a RP might use to determine uniqueness is the level of
proofing they require on 1) each of the attributes and 2) the set of
attributes.

My experience with RPs aligns with Julian's. While RPs usually ask for
uniqueness from their digital supplier they do not do so in the manual
world. My tactic has been to ask why they are asking for it in the digital
world and not in the manual world. The discussion around this question
(usually around 1) their perceived benefit and 2) the additional cost
versus their perceived benefit) leads to them dropping that requirement
from their digital supplier.

The "imposter" discussion usually takes the same path. Asking the RP how
they deal with imposters in the manual world usually leads to a conclusion
that they can employ the same tactics and processes only using digital
data. Cost effectiveness is usually a big part of the discussion. This
should not be likened to paving the cow path. What usually happens is that
they realize that, in the digital world, they might be able to detect an
imposter faster because they have faster access to the data they use to
detect imposters. In some cases, they may realize improved detection
because the proofing data is likely better than they have available in the
manual world.

It is my opinion that, as their processes evolve in the digital world, they
will become faster at imposter detection and resolution. It is also my
opinion that prevention of imposters before they happen, like the totally
secure system, is, if not impossible, not a cost effective goal to achieve.

Ken Dagg

On Friday, 18 March 2016, Julian White <[email-masked]> wrote:

> In my view it is for the RP, or identity federation scheme, to decide
> which attributes are required in their context. They select sufficient
> attributes that give them uniqueness (in their context) if that is
> required, e.g. SSN for some services (though I would advise against it!).
> The purpose of the proofing process is to express to what level of
> confidence that those attributes are true and belong to the person
> presenting them, be they name, address, dob, email address, SSN etc.
>
> On 17 March 2016 at 21:49, Joanne Knight <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> b) an identity of such rigour that their (or the university's)
>> eligibility for public funding can be established and
>> Therefore you are probably looking at P2 or P3 depending on the
>> level/type of qualification. (I might want P3 if the qualification is for
>> brain surgeon or commercial pilot).
>>
>> From: Rolf Brugger [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
>> To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> levels of uniqueness described by Joanne. In each of the three levels a set
>> of attributes is used to determine if an identity is unique within a
>> > [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] Sent: Friday,
>> 11 March 2016 5:51 a.m.
>> > To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> > 268 15 15, direct +41 44 268 15 89 [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>,
>> > http://www.switch.ch
>> >
>> >
>> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> direct +41 44 268 15 89 [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>,
>> http://www.switch.ch
>>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Kenneth Dagg
Independent Consultant
Identification and Authentication
613-825-2091
[email-masked]

---

From: Eric Goodman <[email-masked]>
Date: Fri, 18 Mar 2016 18:32:25 +0000

I would expect (though could be wrong) that the issue isn’t just imposters, but as much about enforcement of separation of duties for the same entity. If I give one of your accounts review rights and another approval rights, then there’s an SoD issue.

So the only thing I was thinking would be worth measuring within the IdP is whether the LoA registration process includes duplicate resolution. I don’t know that any assurance profiles/VoT’s I’ve seen include that as an explicit requirement. I.e., what’s to stop me from having two accounts both vetted to a strong degree and the IdP doesn’t recognize them as the same person.

But your point is compelling: Is identity matching internal to an IdP terribly irrelevant in a federated world? What value does an RP get by knowing that this identity was checked against duplication within an IdP if I can separately create an account (with an equally high LoA) through a completely different IdP? I don’t see what IdP-managed trust measure/indicator is going to help unless you limit your use cases to those involving a single IdP, in which case the need for a profile and standardization is less pressing.

--- Eric

From: vot [mailto:[email-masked]] On Behalf Of Julian White
Sent: Friday, March 18, 2016 6:19 AM
To: Joanne Knight
Cc: Rolf Brugger; [email-masked]
Subject: Re: [VoT] How to express duplicate checks with VoT?

I would say, as I have in the ISO 29003 discussions, that uniqueness is in fact irrelevant in terms of the level of proofing. I see no need to know whether that set of attributes is proven to be unique by the proofing provider. Uniqueness is highly dependent on the context, which raises all sorts of problems if you have an identity federation (how do I know its unique across the federation? If, as an RP, I can can cope with non-uniqueness across the federation then non-uniqueness within the proofing provider is also not a problem).

In my view it is for the RP, or identity federation scheme, to decide which attributes are required in their context. They select sufficient attributes that give them uniqueness (in their context) if that is required, e.g. SSN for some services (though I would advise against it!). The purpose of the proofing process is to express to what level of confidence that those attributes are true and belong to the person presenting them, be they name, address, dob, email address, SSN etc.

In my dealings with RPs they are confused about this and ask for "uniqueness", this is usually followed up with "because we can't let people register multiple identities". There is a lack of understanding that, assuming the proofing process is working correctly, it doesn't matter how many times you enrol you are proven to be the same person each time; i.e. multiple enrolments lead to the identification of the same person being bound to the same attributes. Therefore it isn't actually a problem in terms of uniqueness.

More often than not the ask for uniqueness is really an expression of how well the system defends itself against impostors (different people registering for the same attributes) which is actually the point of the different levels of proofing (the higher the levels of proofing the harder this should become). Demanding uniqueness doesn't actually fix the impostor problem, you just introduce a time trial to the process; the first person to get bound to those attributes locks out other people; if the first person to claim them was the impostor you've now locked out the genuine person - they now have a hell of time unpicking a mess not of their making. If the system defends against impostors properly at the higher levels then the uniqueness adds little value since I can only bind those attributes to the correct person anyway.

The thing that may need to be unique is the account/record at the RP, and its the RP's responsibility to manage that. This is a problem they have regardless of whether the proofing provider tells them its unique or not because they often have multiple on-line and offline channels that deal with their customers, this forces them to understand how to match different representations of the identity to the same account which tends to work across channel and within the same channel.

So in summary it doesn't drive any real value in the proofing provider to do this, its just a cost of effort for little gain that the RP is going to repeat regardless if they care about uniqueness.

Regards,

Julian.

On 17 March 2016 at 21:49, Joanne Knight <[email-masked]<mailto:[email-masked]>> wrote:
The short answer to your question - No.

Cheers

-----Original Message-----
From: Rolf Brugger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, 17 March 2016 11:35 p.m.
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

First level:

Second level:

Third level:

cheers

Rolf

On 11.03.16 02:56, Joanne Knight wrote:
> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Friday, 11 March 2016 5:51 a.m.
> To: [email-masked]<mailto:[email-masked]> Subject: [VoT] How to express duplicate checks with
> VoT?
>
> Hi all,
>
> 268 15 15, direct +41 44 268 15 89<tel:%2B41%2044%20268%2015%2089> [email-masked]<mailto:[email-masked]>,
> http://www.switch.ch
>
>
> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/vot
>

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15<tel:%2B41%2044%20268%2015%2015>, direct +41 44 268 15 89<tel:%2B41%2044%20268%2015%2089> [email-masked]<mailto:[email-masked]>, http://www.switch.ch

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

---

From: Joanne Knight <[email-masked]>
Date: Sun, 20 Mar 2016 19:46:18 +0000

The first point of scoping I would suggest is to determine if you are talking about uniqueness of the identity or uniqueness of the entity.

From: Ken Dagg [mailto:[email-masked]]
Sent: Saturday, 19 March 2016 6:39 a.m.
To: Julian White
Cc: Joanne Knight; Rolf Brugger; [email-masked]
Subject: Re: [VoT] How to express duplicate checks with VoT?

Here, here!!!

I have been a lurker on this group for a while but felt compelled to add my to cents to this discussion as it is, I believe, an important point to scoping the discussion as it proceeds.

I agree fully that determining the uniqueness of a subject is totally the responsibility of the RP. It is their service delivery and they have to determine what they require in order for them to be assured that they are dealing with a unique subject. I use subject in order to include the IOT in the possible solution. If I'm reading what you say correctly, one of the considerations that a RP might use to determine uniqueness is the level of proofing they require on 1) each of the attributes and 2) the set of attributes.

My experience with RPs aligns with Julian's. While RPs usually ask for uniqueness from their digital supplier they do not do so in the manual world. My tactic has been to ask why they are asking for it in the digital world and not in the manual world. The discussion around this question (usually around 1) their perceived benefit and 2) the additional cost versus their perceived benefit) leads to them dropping that requirement from their digital supplier.

The "imposter" discussion usually takes the same path. Asking the RP how they deal with imposters in the manual world usually leads to a conclusion that they can employ the same tactics and processes only using digital data. Cost effectiveness is usually a big part of the discussion. This should not be likened to paving the cow path. What usually happens is that they realize that, in the digital world, they might be able to detect an imposter faster because they have faster access to the data they use to detect imposters. In some cases, they may realize improved detection because the proofing data is likely better than they have available in the manual world.

It is my opinion that, as their processes evolve in the digital world, they will become faster at imposter detection and resolution. It is also my opinion that prevention of imposters before they happen, like the totally secure system, is, if not impossible, not a cost effective goal to achieve.

Ken Dagg

On Friday, 18 March 2016, Julian White <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Julian.

On 17 March 2016 at 21:49, Joanne Knight <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
The short answer to your question - No.

Cheers

-----Original Message-----
From: Rolf Brugger [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
Sent: Thursday, 17 March 2016 11:35 p.m.
To: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

First level:

Second level:

Third level:

cheers

Rolf

On 11.03.16 02:56, Joanne Knight wrote:
> [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] Sent: Friday, 11 March 2016 5:51 a.m.
> To: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');> Subject: [VoT] How to express duplicate checks with
> VoT?
>
> Hi all,
>
> 268 15 15, direct +41 44 268 15 89<tel:%2B41%2044%20268%2015%2089> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>,
> http://www.switch.ch
>
>
> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');> https://www.ietf.org/mailman/listinfo/vot
>

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15<tel:%2B41%2044%20268%2015%2015>, direct +41 44 268 15 89<tel:%2B41%2044%20268%2015%2089> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>, http://www.switch.ch

_______________________________________________
vot mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/vot

--
Kenneth Dagg
Independent Consultant
Identification and Authentication
613-825-2091
[email-masked]<mailto:[email-masked]>

---

From: Julian White <[email-masked]>
Date: Wed, 30 Mar 2016 16:11:39 +0100

Uniqueness of the entity is a whole world of hurt that may or may not be
important, which is dependent on the RP service.

On 20 March 2016 at 19:46, Joanne Knight <[email-masked]> wrote:

> The first point of scoping I would suggest is to determine if you are
> talking about uniqueness of the identity or uniqueness of the entity.
>
>
>
> *From:* Ken Dagg [mailto:[email-masked]]
> *Sent:* Saturday, 19 March 2016 6:39 a.m.
> *To:* Julian White
> *Cc:* Joanne Knight; Rolf Brugger; [email-masked]
>
> *Subject:* Re: [VoT] How to express duplicate checks with VoT?
>
>
>
> Here, here!!!
>
>
>
> I have been a lurker on this group for a while but felt compelled to add
> my to cents to this discussion as it is, I believe, an important point to
> It is my opinion that, as their processes evolve in the digital world,
> they will become faster at imposter detection and resolution. It is also my