Re: Almost there: Verifiable Claims Working Group Proposal

Thanks Manu,

I'll go through your comments one by one (and anyone else who 
comments) and look at the other documents and try to understand where 
I'm crossed-up.

The only one that really surprises me off the top is that I believed 
that everything was given ID=identifiers in the Registry. I thought 
that's how things were kept track of. But no, only the Subject gets 
one? Holder doesn't get one? Issuer doesn't get one? Claim doesn't get 
one? And checking the validity of the Credential is done some other 
way?  Yikes... I'll have to do a lot of reading about that. ;-)

Steven

On 6/15/16 8:14 PM, Manu Sporny wrote:
> 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
>

Received on Thursday, 16 June 2016 04:51:28 UTC