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

Received on Tuesday, 18 May 2021 21:18:30 UTC