Gareth Oliver
Gareth Oliver
While not relevant when making a direct request form a Wallet to an Issuer endpoint, when going through Wallet Server between the Wallet and the Issuer, application-layer encryption provides a...
Credential Response encryption is not specified for Deferred Credential Endpoint. It also might be nice to be able to provide a new jwk in the deferred credential request to perform...
Resolves Issue #339 The adds in a new credential issuer metadata parameter to support Credential Request encryption. Merging this with the existing credential response encryption was considered, but given we...
Currently, there is nothing that ensures the integrity of the JWK used for Credential Response encryption. When not using credential request encryption, a party in the middle that can mutate...
This is a feature request for a use case we are looking into. It is of interest when: - The Verifier is happy to accept a response within a relatively...
This is opening the discussion as to replace the JWE alg from ECDH-ES to one of the HPKE algs specified in https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-08 *before* 1.0 final. This is opened based on...
This is an attempt to describe the general requirements and reasons as to why someone might want an architecture of a Wallet that contains both a server component and a...
Link to example: https://docs.google.com/document/d/1spjhNkVqTd2E9dDrH7YSNz9xgl6wwdOhS5C9yW29ArE/edit?tab=t.g3vis8bna5i1
per wg discussion this is a proposal for how to do HPKE directly. The approach to allow hpke is to specify a new response_mode by appending .hpke instead of .jwt....
As part of amendment 2 to 18013-5, a mechanism is being added to allow requesting, and returning responses using a ZKP proof system. As DeviceResponse is returned as-is in VP,...