[BBU] Transaction Authors

[danielbachgit]

Problem/Concern

The Legal Architecture diagram depicts Issuers, Holders and Verifiers as Transaction Authors within the Permissioned Write Access domain.

*(https://bedrock-consortium.github.io/bbu-gf/gf_legal/legal_arch/#legal-architecture)

Proposed Solution

In order for a Verifier to be be able to verify a Verifiable Credential, an Issuer must have written the Public DID associated with the Verifier to the blockchain; this needs to be accounted for in the BGF.

[vinomaster]

This is not true. See slides 7 & 8 of the briefing deck.

In a decentralized identity model there is no required awareness or relationship between issuer and verifier. The verifier must be able to establish transitive trust for the credentials presented by the holder w/o knowledge of who the issuer is. The Issuer's DID will be in a Cred-Def on the ledger that can be used to perform verification processing.

[danielbachgit]

I agree that there is no required awareness or relationship between Issuer and Verifier; my question is between the Holder and Verifier. When a Credential Offer is being established between the Holder and Verifier - where does the Holder get the Public DID of the Verifier? The specification (Aries RFC 0160) allows for peer-to-peer 'Invitation Message' exchanges but how then would the Holder 'trust' the Verifier in our Trust Framework if it's public DID is NOT placed on the ledger by a trusted entity?

[vinomaster]

See slides 8 of the briefing deck. The Verifier must register its DID on a ledger. Call it "did:xyz:12345667". In the connection flow prior to the proof request between holder and verifier, the Verifier will present its DID. The holder Wallet software will then use that DID to (a) verifier the DID exists, (b) obtain the associated public key (c0 use the public key to validate the connection between the two entities.

[danielbachgit]

right - I agree that a TRANSACTION ENDORSER (not an ISSUER) needs to ensure that Verifiers are legit before their DIDs placed on chain. Therefore, In order for a Verifier to be be able to verify a Verifiable Credential, <an Issuer [NO]> <a TRANSACTION ENDORSER [YES]> must have written the Public DID associated with the Verifier* to the blockchain; this needs to be accounted for in the BGF.

*after the Transaction Endorser has ensured that the Verifier meets the requisite BBU trust profile.

[vinomaster]

Any trx to the a ledger is a Transaction Author (TA). When an Issuer or Verifier write a DID to the ledger the are in effect a TA at that moment. Depending on which ledger they use a Transaction Endorser (TE) may be required to complete the write. Of course in BBU a TE is required. However, we can not assume that a Verifier uses BBU.

A TE must ensure that a TA is legit ... A TA will be a Issuer and /or Verifier depending on the role in a given situation. ACME has one DID on BBU but is some cases is an Issuer and in others Acme is a Verifier.

[danielbachgit]

I'm fairly certain that we are in agreement but I am not communicating my point which business focused, not technical. To make it clear to the reader that, even with a Public-Permissioned ledger, where everyone has read access, the ability to read the ledger will not get you too far. Only Verifiers who are trusted and have their public DID(s) on the ledger will be able to receive and process Verifiable Proofs from consenting Holders.