W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > May 2015

Re: [identity-credentials] Clarity of definitions: Credentials, unbound identity, identity hardening, and bound identity

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 27 May 2015 16:28:57 +0200
Message-ID: <CA+eFz_LdDGkjM4AEtg+9ern+CAdjZ_=UsUC_2X7SXrML=MTBLg@mail.gmail.com>
To: Erik Anderson <eanders@pobox.com>
Cc: Web Payments IG <public-webpayments-ig@w3.org>
Can you help clarify a few things for me (for want of pictures I have used

On 26 May 2015 at 23:22, Erik Anderson <eanders@pobox.com> wrote:

> Please comment on the below definitions. I hope this adds clarity to the
> identity process.
> Credential: Is a professional or personal qualification, achievement,
> quality, or piece of information (governmental, official, legal or
> industry) about the background of an individual or entity such as a name,
> home address, government ID, professional license or designation, or
> university degree, typically used to indicate suitability. The use of
> credentials to demonstrate capability, membership, status, and minimum
> legal requirements is a practice used in society for ages to inspire trust
> and loyalty towards those accountable to a generally accepted responsible
> authority, institution or company.

The way this would be achieved in technology is not dissimilar to how
claims based authentication works today. A credential is a
claim/attestation, by an issuer that the subject of the credential has a
particular property or characteristic.

Example1: XYZ corp claims that person 123 is a US Citizen with a permanent
residence in the USA.
Example2: ABC corp claims that person 345 has SSN 123456789

On their own these credentials have very little value. If the consumer of
the first credential trusts XYZ corp (KYC agent?) then they will trust that
person 123 is indeed a US citizen BUT they have no way of knowing who
person 123 is or if the presenter of this credential is in fact person 123.

> Unbound identity: is a tokenized form of credential(s) created for an
> individual(s) which cannot hijacked and/or extracted from the unbound
> identity token by an unauthorized user be it for unintended  or intended
> purposes.

I am not clear on what you mean by tokenized (it's loaded term, especially
in the payments industry where a token is often understood to be an opaque
key for a PAN).

I assume an unbounded identity to mean a combination of credentials tied to

Example3: A document contains the two credentials above, claims that person
123 (identified by XYZ corp) and person 345 (identified by ABC corp) are
the same legal entity and is signed by EFG corp.

Assuming the consumer of this document trusts EFG corp then this unbounded
identity is a combination of credentials that are trusted to belong to the
same entity.

To this point there has been no requirement to interact (in real time) with
the physical world. These credentials could have been validated by each
issuer (ABC corp, XYZ corp and EFG corp) sometime in the past.

> Identity hardening: is the marriage of credentials and technology by way
> of a process where an unbound identity is combined with technologies
> (geolocation, biometrics, multi-sig, hardware devices and hardware tokens)
> to confirm that the unbound identity and the person connected to the
> technologies are one and the same.

To harden this identity we must "tie it to reality". The problem is, anyone
with the document in Example3 can present it and claim to be the subject of
that document. In order to harden this identity we require a way for the
holder to prove they are also the subject.

This can be achieved through technology by having biometric data in the
document that can be verified by the consumer or the presenter must be able
to sign a challenge with one of the keys used to sign the document or....
some other mechanism.

My question was, is this hardening step required at the time of the
transaction in all scenarios? If we say yes then I see a number of use
cases being impossible like recurring payments that are pre-authorised.

I also think we need to distinguish between the two requirements for
identity in payments that are often conflated:

   1. Identify the transaction initiator and decide if they have authority
   to access the account that is the source of funds? (Authentication)
   2. Identify the parties to this transaction? (KYC, AML etc)

My suggestion is that requirement 2 can be satisfied prior to the actual
execution of the payment.

> Bound identity: is a hardened form of an unbound identity.
> NOTE: Identity and Credentials together and combined legal entities and
> individuals, create the lego building blocks that shape the matrix that
> facilitates the efficiency in the automation of KYC/AML whilst reducing
> layers of friction and costs. It is incumbent however upon the the
> financial institution, insurance company or service provider (if they so
> choose) to be ultimately responsible for the final hardened identity and
> its assurances.
> Erik Anderson
> Bloomberg R&D & W3C Web Payments IG/SG
Received on Wednesday, 27 May 2015 14:29:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:36 UTC