Torsten Lodderstedt
Torsten Lodderstedt
define how wallet attestation is implemented based on client attestation draft
The module drafts for client attestation (used for wallet attestation), verifier attestation (OID4VP) and status list define the schemas of the different assertions but do leave flexibility regarding the way...
Profile must describe how the `nonce` and `aud` in the HB JWT is determined from request parameters and context of the transaction.
Use of DNSname SAN in credentials with x5c and web based lookup forces hosting of the jwt-issuer metadata at the top of the FQDN. Can we relax the requirement and...
I'm not sure whether the profile should make the JSON Serialization mandatory. Are there libraries avalaible? Are there enough use cases justifying it? So far, I see JAdES as a...
Currently, the profile requires the implementation of Refresh Tokens for Credential refresh. This is especially needed for refresh of short living credentials and for gathering fresh copies of RP-specific/ephemeral credential....
Currently, implementations can protect the PoP for wallet attestations (https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth) by: - making it short lived - making it one time use - binding it to a protocol artifact like...
The current description in section 6.1. is tight to W3C VCs. Here is one example > The path_nested object inside an Input Descriptor Mapping Object is used to describe how...
In EUDI Wallet context, we frequently hear the requirement to authorize transactions (electronic signatures and payments) with the wallet. At OSW, a couple of us discussed the idea to make...