W3C home > Mailing lists > Public > public-credentials@w3.org > June 2016

Re: Proof of possession

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Tue, 14 Jun 2016 22:14:06 +0100
To: Dave Longley <dlongley@digitalbazaar.com>, public-credentials@w3.org
Message-ID: <ab3e5ca5-f4f6-6193-1af1-b7d7989f24a4@kent.ac.uk>

On 14/06/2016 18:14, Dave Longley wrote:
> On 06/14/2016 11:10 AM, David Chadwick wrote:
>> On 14/06/2016 15:59, Manu Sporny wrote:
>>> On 06/14/2016 10:34 AM, David Chadwick wrote:
>>>> And if I do not want to register a subject ID, can I simply use
>>>> my public key as my subject ID and submit the same string twice?
>>> In theory, yes.
>>> In practice, no one has built out that kind of system because it
>>> doesn't address many of the use cases we have. Some see it as an
>>> evolutionary dead end - it's great for pseudo-anonymity, but
>>> doesn't address the vast majority of multi-origin use cases we
>>> have.
>> I agree that with multiple credential issuers (I assume that is what
>> you mean by multi-origin) some sort of correlating handle is needed
>> in order to prove that all the credentials belong to me.
>> So I see why a registered globally unique ID is useful to solve this
>> problem.
>> But if I had a public key specifically minted for one
>> requester/relying party, and all my issuers would bind my claims to
>> this, then I could prove possession of all credentials to this
>> requester/relying party. And I would not actually need to register
>> this public key anywhere as I can always prove possession.
> Yes, until you lose your key or it becomes obsolete. What you're
> suggesting would work just fine with the data model and syntax we're
> proposing, it just has trade offs in the approach.

Thanks. Its is nice to know it is supported. The only problem is that
neither of the basic architecture diagrams that have just been
distributed actually show support for it.

BTW, losing a key, physical or electronic, is always a hassle, but it is
not irreparable.


Received on Tuesday, 14 June 2016 21:14:25 UTC

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