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

Julian White <jwhite@nu-d.com> Wed, 30 March 2016 15:12 UTC

Return-Path: <jwhite@nu-d.com>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8F012D161 for <vot@ietfa.amsl.com>; Wed, 30 Mar 2016 08:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nu-d.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaTxLIioqLpB for <vot@ietfa.amsl.com>; Wed, 30 Mar 2016 08:12:01 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6036812D108 for <vot@ietf.org>; Wed, 30 Mar 2016 08:12:01 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id 127so101479703wmu.1 for <vot@ietf.org>; Wed, 30 Mar 2016 08:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nu-d.com; s=nud; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evFNYxY+IzIvEMZdjVib1836cV7qpNq5os4T4DU3XOQ=; b=ln5nVIAr8CKnLIY/7UnITkk5Kq21pBOy+pQeNRgbgvoNhvcohFIVbAgWUyaWo2759N Dyh2ed3kOhwSk47JRvvAwhy0zCHJ7fNYe48UIVIY6cFv1BBOIE8My9YovNa41x9FDkCw 7Qe6YjBTcLkmOSnHQ3/uJ//ucgnvnjaF9pvkw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evFNYxY+IzIvEMZdjVib1836cV7qpNq5os4T4DU3XOQ=; b=SNMeJL//ztVaCMwfatvlI5KAxJ0Gir2xrexCDorl+moKq2HGCkXBySgQozXMmTbxRv LC1a/4bQA6WTUOtPX9j4OaSoo5hSmkQMIY2mswlED/IxLwTb5zHxwheHukFDwvptfKRZ WHQRn1jilqDQLkqWiuhByiKIhr4k1isDwNiX9A865/e8sCscetJMaFj13TEJc9KacOjG BfoBqoaehhY7L24Zss0evJusU7V/OVJkBuhjccotxe4b4Cykc7GRwpKBM1W2nKOFQ/3U ep+o6c8VFbyNzz1tGHXgd5V3tpOkyd/WzGkzbySIAMKARlvXBGDUc3QtBHHpQF9LfsAj j+7g==
X-Gm-Message-State: AD7BkJK3CWr4RE4MrjscH9+FHRZ8CfksC4WVfte2LeS0jONt3+V6SHURNW4+HNfgBOnVnpLE+AEzXjUMKPbkWyuR
X-Received: by 10.194.184.38 with SMTP id er6mr9722596wjc.93.1459350719400; Wed, 30 Mar 2016 08:11:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.121.7 with HTTP; Wed, 30 Mar 2016 08:11:39 -0700 (PDT)
In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C81DA5@AKLDRMBX03.dia.govt.nz>
References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> <CAL4gWiLVGC+z-p8apxO042yVBDPVMTxkciWRpQ8UPo8giSPZDA@mail.gmail.com> <CAKSgTGQ78X4aQ7wzHtz7cVKPq5HZ_txO+zJbLTe0K7JkV3Uo_A@mail.gmail.com> <569AD906E45DB44A8AFF11D61F5DA7910155C81DA5@AKLDRMBX03.dia.govt.nz>
From: Julian White <jwhite@nu-d.com>
Date: Wed, 30 Mar 2016 16:11:39 +0100
Message-ID: <CAL4gWiL_3jMafBH6QUcHf=6L3K4NztWoGK=P4QoE9zLj94ZfeA@mail.gmail.com>
To: Joanne Knight <Joanne.Knight@dia.govt.nz>
Content-Type: multipart/alternative; boundary=047d7ba97a1c3baaef052f4591ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/Opf507w_SAX22ys8U5JPmfbv3K0>
Cc: Ken Dagg <kendaggtbs@gmail.com>, Rolf Brugger <rolf.brugger@switch.ch>, "vot@ietf.org" <vot@ietf.org>
Subject: Re: [VoT] How to express duplicate checks with VoT?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2016 15:12:06 -0000

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 <Joanne.Knight@dia.govt.nz>; 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:kendaggtbs@gmail.com]
> *Sent:* Saturday, 19 March 2016 6:39 a.m.
> *To:* Julian White
> *Cc:* Joanne Knight; Rolf Brugger; vot@ietf.org
>
> *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 <jwhite@nu-d.com>; wrote:
>
>
>
> 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 <Joanne.Knight@dia.govt.nz>;
> wrote:
>
> 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:rolf.brugger@switch.ch]
>
> Sent: Thursday, 17 March 2016 11:35 p.m.
> To: vot@ietf.org
> 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?
>
> 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:
> > 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:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51 a.m.
> > To: vot@ietf.org Subject: [VoT] How to express duplicate checks with
> > VoT?
> >
> > 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 rolf.brugger@switch.ch,
> > http://www.switch.ch
> >
> >
> > _______________________________________________ vot mailing list
> > vot@ietf.org 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,
> direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
>
>
> --
> Kenneth Dagg
> Independent Consultant
> Identification and Authentication
> 613-825-2091
> kendaggtbs@gmail.com
>