Re: Almost there: Verifiable Claims Working Group Proposal

On 06/15/2016 09:43 PM, Steven Rowat wrote:
> I've finished a very rough first draft of a flow diagram

https://dl.dropboxusercontent.com/u/4805031/VC-Basic-Architecture-SR-DR1B.pdf

Really cool, Steven.

This is one of the reasons I love community groups.

I've never once pictured the architecture and flows like that, so it's
fascinating to see someone else formulate it in a way that's completely new.

Some thoughts that are meant to be constructive:

The title feels too long. The words "self-sovereign" and
"implementation" seem out of place. Perhaps something like "Lifecycle of
a Credential in the Verifiable Claims Architecture"? Still too long...
"Lifecycle of a Verifiable Claim"? Not quite accurate. "Roles and
Documents in a Verifiable Claim Lifecycle"?

What you label as entities/actors are really roles.

The diagram seems to communicate that subject identifiers are created
more often than they are. For example, for your entire diagram, you
should show one subject identifier being created. Instead, you show 12.
Perhaps you're communicating that those are checks on the subject
Identifier? If so, that happens twice in your diagram, but you have it
happening 12 times.

Bottom left of diagram, time stages 1 and 2. Claims don't exist on their
own as documents. Claims are always bundled up into a credential. Look
at Example 2 here:

http://opencreds.org/specs/source/claims-data-model/#expressing-claims-in-json

Stage 2, holder is issuer - this is one of those corner-cases that
should never end up on a diagram. The only time the holder is also an
issuer are scenarios like a deparment at a university (they hold claims
that say they're a accredited program, and they also issue claims to
students), or an department that does KYC at a bank (they hold claims
that say they're "level 4 certified", and they issue claims to their
customers, etc.

Stage 2, thinking more about this, it doesn't make sense to me. Stage 1
is a self-issued claim (or the setup of one, where the issuer, holder,
and subject are the same). I don't really know what you're trying to
show in stage 2.

Stage 3, the issuer aggregates claims into a credential (not the
Holder). The holder can then aggregate credentials into an "Identity" or
"Identity Profile" or "Persona" - whatever we end up calling that thing
that contains credentials.

Stage 4 is spot on, except for the id check by the repository. I guess a
repo could check, but it's done that already when the holder logs into
their repository. The only check that needs to happen after that is
checking the validity of the credential being stored before it's stored.

Stage 5, the inspector checks the syntactic validity of the credential
(is it formatted correctly, is the signature valid) and if that checks
out, it may apply business rules to see if the semantic validity of the
credential is solid (hmm, the "over the age of 21" credential has been
issued by a known shady identity proofing service... could be a teenager
trying to use a fake age, reject them).

Stage 6 is right.

Ahh, and I finally got the cross-hatched yellow background as being the
"all encompassing registry", which is why the "ID" callouts bounce
outside the lanes and come back into the lane.

I don't know how you want to change the diagram based on the above. It
would be good to hear back from others in the community to get their
impression on the diagram and where it may be best used.

I don't know what to call this type of diagram... got a name for it?
It's like a combination of swim lane and entity-interaction and
information flow.

-- 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 Thursday, 16 June 2016 03:14:41 UTC