Re: Feedback requested: VC Architecture Diagram

On 06/14/2016 05:08 PM, David Chadwick wrote:
> 1. The storage of the subject identifier in the repository is 
> optional, as per earlier discussion with Manu today, but is seen to 
> be mandatory in both diagrams. It should be marked optional.

Hmm, sorry, something I said made you jump to the wrong conclusion.

I think part of the issue is that we keep having discussions in the
abstract. For example: "Is X possible with the Verifiable Claims data
model?"

The answer to that question is probably "Yes".

I interpreted your question about the subject identifier as a public key
identifier like this:

"If one wanted to do proof of possession, but wanted to issue claims to
public keys and do proof of possession using a public key, is writing
the subject identifier (and key information) to the identifier
repository mandatory based on the current Verifiable Claims data model"

... and the answer to that question is "No, writing the subject
identifier to the registry is not necessary", because the subject
identifier is a public key and the fingerprint is good enough for most
cases IF you want to deploy an ecosystem where the subject identifiers
are public key identifiers.

I hope I'm being clear when I say that a non-trivial number of us think
that sort of ecosystem would be really bad for end users. Let me
re-state that to be crystal clear. We have considered that approach and
come to the conclusion that it would result in an ecosystem that will
not scale wrt. adoption (unless there are some serious advances made in
cryptographic key recovery).

Someone that disagrees is welcome to build an alternate ecosystem based
on the assumption of public key identifiers as subject identifiers for
claims. You can even use the verifiable claims /data model and syntax/
to do this. However, the verifiable claims architecture does present
what we think the ideal outcome should be (and that vision is NOT public
key identifiers as subject identifiers).

So, -1 for marking the identifier registry as optional. It paints a
future that I think many of us don't want (but others are welcome to
fork the architecture and travel down a different path, because we may
be wrong).

> 2. Verifying identity ownership can be done by direct communication 
> with the holder (in the case where the holder is the subject and the 
> identifier is a public key) but this option is not represented in the
> diagram.

I hope the above explains why it's not presented as an option.

> In terms of the arrows, I prefer Dave Crocker's version

Good to know, thank you. Why? (out of curiosity)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/

Received on Wednesday, 15 June 2016 01:03:30 UTC