Proof-A-Palooza: Standardizing Presentation Request Language for Verifiable Credentials & VC’s in Application (Part 2)

From IIW

Proof-A-Palooza: Standardizing Presentation Request Language for Verifiable Credentials & VC’s in Application (Part 2)

Wednesday 9B

Convener: Nathan George & Martin Riedel

Notes-taker(s): Alexander Tam & Nathan George

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:

1. Notes from Alexander Tam:

how an issuer gives a credential determines how a holder can share, eg. if they can share one component of the credential

- credential
- subset of claims
- subset of zero knowledge prove

- generate a proof
- how to structure building the proof in the credential
- merkle tree and envelope of all claims in the credential


- json based verifiable credential
- no zkp claims
- proof request format
- schema that outline what the verifier wants

- generate
- claim proofs that sit along the claim
- move into proof body


- calls the claim a proof instead

- probably best to call them presenting a credential item

- credential request, (credential offer), credential send

- proof request, (proof offer), proof present

- gives the party the optional to offer an alternative, eg. offer >21 instead of age

- schemas aren't owned, and are immutable. To update, create a new schema that references the old one

- placed on the ledger

- proof block similar to workday,

- proof request, want claim Y, and a property of that claim, not necessarily the property itself, eg >21

- check the crypto (signatures are correct, but they gave me the data I waned)

- comment

- problem, requires the holder to look through their credentials and choose which the verifier wants
- wallet would know which crednetial is more appropriate
- does holder ever have the power to do this? Don't want vista situation

- can automate this but may want more sophasitcated
- sovrin is thinking of an overlay: schema of what is appropriate to share with certain parties that are supported by some third party, eg. EFF says you should only share X with websites
- no good solution yet, but not a problem we have now since small amount of use cases

- issuer can help by defined a good credential, preventing the holder from oversharing
- could be an access token
- however gives too much power to issuer, no longer self sov

- comment

- attack vector with infinite proof request by figuring out what the holder is willing to share
- not a problem yet since immature ecosystem
- attack vector by asking proof request for small amounts of data that eventually reveal too much over a long time
- more of a governance framework problem, GDPR would be helpful here by forcing to ask for as little as possible

- civic, workday

- specifies what combinations of credential items can be shared, does sovrin?
- yes, calls them attributes which are bound to linked secret to show ownership of the credential (join identifier or schema def)

- sovrin

- issuer doesn't define how and what holder discloses to a verifier
- trustframework definition takes care of cases like expiry credential item

- can't share the proof for another party to verify


- combine workday and sovrin?
- yes, can provide a combinature proof of credential
- can you make a wallet to handle different types of credential
- try and standardize proof request procedure first (same schema)
- 80% the same currently
- eg. sovrin driver, workday workplace, use both for a loan
- have to solve same schema problem first

- standards for proof request working group

- comment

- microsoft doing something similar, wants to join standards
- jwt instead of linked signatures
- use in openidconnect
- use did not linked secret for issuing crednetials

- standardizing on crypto is the least of our concerns, since most use the same curves

- might be a problem if agent vendors don't comply

2. Notes from Nathan George

We discussed selective disclosure data architecture and how to request a subset of a credential’s data and combine data from multiple credentials.  We also went into vocabulary for those selected parts of credentials in our systems and discovered a lot of overlap and potential for standardization.  A list of emails was gathered for use to kick-start a more official standardization effort.  Bjorn of Workday, Martin of Civic and and Nathan of the Sovrin Foundation (all co-presenters in the session), can provide more information to those who are interested in joining.

Wed 9B 1.jpg

Wed 9B 2.jpg

Wed 9B 3.jpg