Re: Feedback requested: VC Architecture Diagram

+1 to Manu's sentiments

Accreditrust's viewpoint is aligned with Manu's comment, "Verifiable Claims
ensure that the entity that a website is speaking to has a certain set of
qualifications that have been vetted by a trusted 3rd party. It also
ensures that those qualifications can be asserted across multiple origins.

+1 to the Diagrams from Dave L.

Eric


On Tue, Jun 14, 2016 at 9:03 PM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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/
>
>