Verifiable Credentials Q & A?

Verifiable Credentials Q and A?

Wednesday 8K

Convener: Paul Dietrich

Notes-taker(s): Paul Dietrich

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Dan Burnett and Stephen Curran (Indy community) joined to answer our questions.

VC was written without requiring DIDs. Why. What are the intended applications? Claims issued by domains about other domains?

DIDs were actually spawned out of the VC work. VC does not define identity or identity systems. They are really about a set of claims provided together about an identifier.

Generally we can think of VC as signed authenticated data that can be shared between parties and clearly identify the issuer of the credential.

VC verify the issuance of the claim, not the truth of the claim.

DIDs arose out of this work in the following. When trying to define the identifiers required for VC, they looked at email, domain name etc. it became clear that there wasn’t an identifier that could not be taken away.

When I receive a credential from an issuer using DID1 and share that to a verifier using DID2. How does the verifier connect that DID1 and DID2 are the same entity.

Stephen — In the indy hyper ledger work this is called blinded link secret in Indy terminology. Its a piece data derived from a holder private key.

Or what going into credential is the public DID of the holder. (Indy does not do this).

VC spec has a place to say there is a subset to the claim. Credential Subject: ID is the ID of the subject.

The blinded secret replaces the ID in the subject identifier.

When presenting a credential ( a set of claims). indy has selective disclosure where you report only some of the claims in a credential.

There are quite a few places in the draft that leave options to remove stuff like ZKP etc. Can you explain?

This is for the standard development process. If they are not absolutely sure that they will get full testing support for the features, they mark it as such so they don’t have to repeat steps in the standards process to remove.

Can you share some future expectations on revocation? Is it expected that the verifier? It seems like the burden is on the verifier to check for revocation and on the issuer to post revocation?

(Further Notes lost due to dead laptop battery).