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

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

workday

- 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

sovrin

- 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

comment

- 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 identity.com and Nathan of the Sovrin Foundation (all co-presenters in the session), can provide more information to those who are interested in joining.