Implement Verifiable Credentials
amika-sq opened this issue · comments
iOS needs to implement Verifiable Credentials, so that a consumer of the SDK can create/verify/etc a claim required for tbDEX
[after discussion with @amika-sq] this may not be needed. a client will only need
PresentationExchange.selectCredentials
when fulfilling therequiredClaims
of theoffering
and providing the associated data to theclaims
of therfq
good to close @amika-sq ?
Wallet also needs PresentationExchange.satisfiesPresentationDefinition
Wallet also needs PresentationExchange.satisfiesPresentationDefinition
ah gotcha, assuming so we can present to the user why certain credentials didn't satisfy a PD.
if no matching creds are found, selectCredentials
will return an empty list while satisfiesPresentationDefinition
will return an errors object explaining why.
if 2/5 matching creds are found, selectCredentials
will return a list size of 2 which would be insufficient to satisfy the claims requirements, while satisfiesPresentationDefinition
would return an errors object describing which requirements failed.
makes sense, good catch thank you!
Wallet also needs PresentationExchange.satisfiesPresentationDefinition
ah gotcha, assuming so we can present to the user why certain credentials didn't satisfy a PD.
if no matching creds are found,
selectCredentials
will return an empty list whilesatisfiesPresentationDefinition
will return an errors object explaining why.if 2/5 matching creds are found,
selectCredentials
will return a list size of 2 which would be insufficient to satisfy the claims requirements, whilesatisfiesPresentationDefinition
would return an errors object describing which requirements failed.makes sense, good catch thank you!
Yes, more specifically, a Wallet can use this method to find the Offerings where the customer already has VCs that will satisfy the requiredClaims - therefore eliminating Offerings that she doesn't qualify for and not bothering to show those Offerings to her.
Here's an example
oh truuuuue. yeah super good catch
Closing in favour of #3