Re: Verifiable Conditions - implementation progress

Thanks guys, I'm moving this to Github issue https://github.com/w3c-ccg/verifiable-conditions/issues/3, please let's discuss the pros and cons of each there and perhaps have a quick recap next meeting and make a decision.

_________________________________________
[https://image.ibb.co/gEfyRz/profile.jpg]
Jack Tanner
Blockchain and SSI developer | Gimly
p: (+31) 6 2216 5433
w: gimly.io<https://gimly.io> [https://cdn1.iconfinder.com/data/icons/logotypes/32/square-twitter-32.png] <https://twitter.com/gimly_io>  [https://cdn1.iconfinder.com/data/icons/logotypes/32/square-linkedin-32.png] <https://www.linkedin.com/company/gimly-blockchain>
[https://cdn1.iconfinder.com/data/icons/logotypes/32/square-twitter-32.png]<https://twitter.com/@theblockstalk> [https://cdn1.iconfinder.com/data/icons/logotypes/32/square-linkedin-32.png] <https://www.linkedin.com/in/jack-tanner/>

________________________________
From: Manu Sporny <msporny@digitalbazaar.com>
Sent: 18 May 2021 11:18 PM
To: Orie Steele <orie@transmute.industries>; Markus Sabadello <markus@danubetech.com>
Cc: Jack Tanner <jack@gimly.io>; public-credentials@w3.org <public-credentials@w3.org>; Caspar Roelofs <caspar@gimly.io>
Subject: Re: Verifiable Conditions - implementation progress

On 5/18/21 3:13 PM, Orie Steele wrote:
> yes, likely the decision to keep the type a single string is reflective of
> a general concern Manu has raised many, many times...

I'll spare Jack the "don't build footguns" lecture since that's not the direct
reason this time. :)

The direct reason is that we're trying to make matching against Verification
Method type simple and straightforward. This is supposed to be a cryptographic
suite type that does one thing. Do a single string comparison, you're done.

This rule doesn't prevent what Orie was describing (sharing cryptographic
material (e.g., keypairs) between different verification methods -- in the
general case, don't do that, it'll bite you -- you've been warned).

Fundamentally, you may be modelling the cryptographic conditions in a strange way.

Jack, have you considered not using type to specify ANDs and ORs and using a
property instead? It's a nuanced but important difference (and forgive me if
you have as I haven't spent as much time thinking about this problem as you
probably have):

"requireAllConditions": [VM1, VM2, VM3]

"requireAnyCondition": [VM3, VM4, VM5]

It feels like you can build all logical variations by then nesting other VMs
inside? I haven't done the work to figure out if this is true and wanted to
check with you before we tried going down that path.

Also, have you considered date-stamping your Verification Method type? It's
often good practice to just assume the first iteration of this thing is going
to be wrong... a date-stamped type, such as "VerifiableCondition2021" gives
you that escape hatch when you want to improve this later on without having to
worry about backwards compatibility within the Verification Method.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches