Default presentation of credentials #886
Conversation
Magnus-Kuhn
added
wip
Magnus-Kuhn
requested review from
Milena-Czierlinski,
jkoenig134 and
tnotheis
Magnus-Kuhn
removed
the
wip
| presentationFrame: credential.defaultPresentationConfig.presentationFrame, | ||
| verifierMetadata: credential.defaultPresentationConfig.keyBinding | ||
| ? { | ||
| audience: "defaultPresentationAudience", | ||
| issuedAt: Date.now() / 1000, | ||
| nonce: "defaultPresentationNonce" | ||
| } | ||
| : undefined |
There was a problem hiding this comment.
do we really need to save those settings in the attribute? Or is is possible to pass them in the UseCase? IMO the used type in the credo lib heavily blows up the generated types - and I don't really see how we set this from e.g. the app.
Additionally: audience and nonce should not default to nonsense values, instead this should also be passed to this method.
There was a problem hiding this comment.
The end goal is that the holder shows a QR code with the presentation that is not prompted like in the OID4VP flow, which allows offline presentation and is more in line with showing a digital ticket. So the configuration has to be stored somewhere and the attribute is the simple choice.
audience and nonce should under normal circumstances be set by the verifier, but in this scenario that's not possible and I don't want to put the effort in to build something without them. So while it would be possible to move them to the use case, I don't see them changed to other values.
If the generated types are problematic, I have no problem with simplifying them - it's easy enough to explain what is correct there without the type
There was a problem hiding this comment.
I still not understand WHO stores that information. Also, how is the verifier transfer the information to the app, when the app is just doing a button press.
There was a problem hiding this comment.
There is no information transfer from the verifier, an example scenario is that you display a QR code with the Heidelbergpass, it is scanned at e. g. the zoo without any further prompting from the verifier. So the holder has to store the information and should get it from the issuer during the issuance, although we haven't decided yet how this happens
There was a problem hiding this comment.
Aren't those changes useless until this decision was done? Also, we could do those changes with a hardcoded config for now and then implement the config storage when we determined who stores what where ;)
There was a problem hiding this comment.
Would it make sense to have a short Teams call where we discuss this?
There was a problem hiding this comment.
I think we should, yeah.
Magnus-Kuhn
added
the
wip
|
Putting this on hold because alternative approaches to presenting outside of OID4VP are being discussed |
Readiness checklist
Description
There are scenarios where a presentation should be created without being prompted by a verifier. This adds a configuration for creating a default presentation to the attribute.