Torsten Lodderstedt

I'm in favor of option 3 as it provides the attestation along with a binding of the presented credentials. Option 2: The wallet attestation is a special function and a...

I think @paolo-de-rosa wanted to remind us of the additional safeguards beyond technical solutions, especially in the EU with GDPR and eIDAS, that might kick in if we don't find...

> ... > On that basis I think we should consider revising the design somewhat to a simpler model which relies on authenticating the verifiers response encryption key as an...

Hi all, I extended the proposal to have two modes now: - “platform trust management mode”: In order to also have an easy to use option for those applications not...

I just added an alternative approach to the document. It uses existing OpenID 4 VP messages. This allows to use signed requests in a secure fashion without the need to...

I reworked the proposal to use existing OID4VP messages. That makes the proposal easier to implement for existing implementers and more powerful (it leverages existing OID4VP security mechanisms on top...

I re-added response_type and response_mode in order to be as close as possible to the OID4VP as is. Only redirect_uri does not make sense for the profile and should be...

Would you suggest we change this for the direct post request, too?

> ### Imported from AB/Connect bitbucket - Original Commenter: peppelinux > assuming that a redirect_uri is equal to the entity id of a client (client_id) there comes to my mind...

The OID4VP spec currently requires key binding. "This specification assumes that a Verifiable Credential is always presented with a cryptographic proof of possession which can be a Verifiable Presentation. This...