Re: proofs for fragments of JSON-LD documents

Relooking at your use case, I don't see a way to achieve what you're after
without expecting the consumer to be able to split the combined document
again so that the proofs can be verified properly. My suggestion would be
instead to have you do some sort of wrapping around it like so. This way
you're not partially signing any portion of a piece of data and you're able
to separate out the assertions from each individual issuer, while also
keeping the ID of the graph together.

{
 "@context": "https://w3.org/2018/credentials/v1",
 "@id": "https://example.com/id-of-combined-object",
 "verifiableCredential": [
{
     ... // other VC metadata,
     "id": "https://example.com/unique-sub-object-id1",
     "credentialSubject": {
           "A1": "ValueOfA1",
           "B1": "ValueOfB1",
     },
    "proof": {...}
},
{
     ... // other VC metadata,
     "id": "https://example.com/unique-sub-object-id2"
     "credentialSubject": {
           "A2": "ValueOfA2",
           "B2": "ValueOfB2",
     },
     "proof": {...}
}
],
}


Note, there's others on here who may have better suggestions, but that's
what I was able to come up with as a potential solution that would allow
you to use LD-Proofs.

-Kyle


On Thu, Nov 26, 2020 at 9:04 AM Andreas Kuehne <kuehne@trustable.de> wrote:

> Hi Kyle,
>
> what would you recommend if our use case has a set of proofs. So we
> don't want to validate all proofs separately. And we have a decent
> number of users, so we don't have amibitions for anything
> 'cryptographically fancy'?
>
> My first idea was to adopt the reference approach of XMLDSig. But set of
> proofs partially signed, only, don't seemed to be considered a good idea.
>
> Greetings,
>
> Andreas
> > I'd think you could either choose to split the Verifiable credentials
> such
> > that they're signing only the data they need to, use multiple proofs as
> > defined in the Linked Data Security specification, or if you have a size
> > constraint and want to play with some fancy crypto then a BLS aggregate
> > signature[1] could be a good option too.
> >
> > [1]: https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-04
> >
> > -Kyle
> >
> > On Wed, Nov 18, 2020 at 7:57 AM Ryan Grant <w3c@rgrant.org> wrote:
> >
> >> When a Verifiable Credential use case (which may require one or more
> >> Verifiable Credentials, depending on the answer to this question)
> >> requires different issuers to sign the matter at hand, what is the
> >> appropriate method of presentation?
> >>
> >>
> >>
> >> On Sat, Nov 7, 2020 at 7:28 PM Manu Sporny <msporny@digitalbazaar.com>
> >> wrote:
> >>> On 11/5/20 10:35 AM, Giuseppe Tropea wrote:
> >>>> In other words, would it be desirable to specify a way for the
> >>>> algorithms to natively operate on portions of JSON-LD documents vs.
> >>>> the whole?
> >>> No, absolutely not -- this is a really dangerous idea, please don't
> ever
> >>> do it. :)
> >>>
> >>> If you can help it, you never want to digitally sign just a subset of
> >>> information. Linked Data Security was designed to avoid this mistake on
> >>> purpose.
> >>>
> >>> The issue with signing subsets of information in an otherwise digitally
> >>> signed document is that a significant number of developers then go on
> to
> >>> assume that /everything/ is signed, when it is not.
> >>>
> >>> Linked Data Security digitally signs everything, both the message and
> >>> *all* of the signing parameters. Don't want something signed? Tough,
> you
> >>> can't do it -- because it will lead to security vulnerabilities.
> >>>
> >>> The correct approach is to verify signatures for all of the pieces of
> >>> information you have and then merge everything together (which is one
> of
> >>> the things that Linked Data is designed to do -- easy merging).
> >>>
> >>> It is possible to create an encapsulating JSON-LD container that isn't
> >>> signed, but even then, important that you avoid that if you can.
> >>>
> >>> Hope that helps. :)
> >>>
> >>> -- 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
> >>>
> >>
>
> --
> Andreas Kühne
>
> Chair of OASIS DSS-X
>
> phone: +49 177 293 24 97
> mailto: kuehne@trustable.de
>
>
> Trustable solutions UG (haftungsbeschränkt), Gartenheimstr. 39C, 30659
> Hannover, Amtsgericht Hannover HRB 219338
>
> Trustable Ltd. Niederlassung Deutschland, Gartenheimstr. 39C, 30659
> Hannover, Amtsgericht Hannover HRB 212612
>
> Company UK Company No: 5218868 Registered in England and Wales
>
>
>
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.