[Openid-specs-digital-credentials-protocols] WTE and PoA in OpenID4VCI

Wed Dec 4 14:20:23 UTC 2024

Hi Sietse,

thanks for sharing your ideas for PoA. To me it seems reasonable to define a new proof type for PoA, especially if the PoA contains multiple credential keys. Can you please explain why you are treating the PoP and the PoA separately? I’m asking since the signature in the PoA object is both, a PoA and a PoP (for the WTE and the credential keys). Would you agree?

best regards,
Torsten.
Am 22. Okt. 2024, 14:36 +0200 schrieb Sietse Ringers via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net>:
> Hi,
>
> Within the EUDI NL Wallet implementation we have recently been making some progress on implementing the WTE. We originally started working based on this suggestion by Torsten https://github.com/openid/OpenID4VCI/issues/355#issuecomment-2236186075, and I have also been reading https://github.com/openid/OpenID4VCI/pull/389 which adds key attestations, but for our sitation neither approaches seems ideal. With this mail I would like to explain our situation and the direction we have taken, and suggest some ways how this might be integrated into OpenID4VCI.
>
> WTE and PoA
>
> The main difference in approach comes from that we plan to use Proofs of Association (PoA) in the NL Wallet. A Proof of Association of a set of keys managed by a WSCD (Wallet Secure Cryptographic Device) is a proof produced by that WSCD that all those keys are managed by a single WSCD. For now we implement that as follows: a PoA is a JWS in JSON serialization format whose body contains all involved keys, and it is signed by all of those keys. This implementation is based on work that the NL Wallet architects, myself included, did with Torsten some time ago.  (Unfortunately this implementation is so new that it is not visible yet on the public mirror of our source code repository, https://github.com/MinBZK/nl-wallet. If you like, I can notify you when it appears there.)
>
> Here is a PoA of two keys, as we have currently implemented it. If you recombine the JWTs to compact serialization, you can use https://jwt.io/ to see that they both validate against the public keys in the payload.
>
> {
>   "payload": "eyJpc3MiOiJodHRwczovL3dhbGxldC5lZGkucmlqa3NvdmVyaGVpZC5ubCIsImF1ZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWFuY2UvIiwibm9uY2UiOiJXMjJsVTY5a29LRlNINUZadW52ck5kanhqbndLRnQzVCIsImlhdCI6MTcyOTQzNzE1MywiandrcyI6W3sia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJGV1Rla3JNY2xFX1hIMzZpaXpBeU9DSWlEQjYtM1U4Z3RCbFpsWDl2YWNZIiwieSI6InI1aUNlYU9NUk1GMENjZkwtRjJaQ2o5TGRUemFwaWtabEFDcXItMVQ1QmMifSx7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoibG5lbFBRaThNTVdxTXV3cE95MWloN2lsaDktV2xYVloya3U3Ri04SHRzRSIsInkiOiJkM3NBbG9nTVd4X2JvYmRCeGdLbmVkcGM5X0VlWFRBYTNOZkhyd1JOZWpNIn1dfQ",
>   "signatures": [
>     {
>       "protected": "eyJ0eXAiOiJwb2Erand0IiwiYWxnIjoiRVMyNTYifQ",
>       "signature": "Fb25pcLORvBIRrEysJKP3U3pbcuOTCkZ9LFOlbNdyR-DDCUEnSzyVZu6u9eavtGyKVo9sK8a_LmyJ2X8YSDSlw"
>     },
>     {
>       "protected": "eyJ0eXAiOiJwb2Erand0IiwiYWxnIjoiRVMyNTYifQ",
>       "signature": "sM7C2ljWgVCztMGBd2bJAU0dg3tUk3ThQFQr3THnmf-YMqvAKSxROgCKJoeFipJTvmVb5CTy77PSSZvh4BODdg"
>     }
>   ]
> }
>
> This can be used both during disclosure (allowing the wallet to prove that the keys of all involved credentials are managed by one WSCD, i.e. preventing credential pooling attacks), but for now I am interested in discussing issuance, where we use it as follows:
>
>
> • The WTE is in our case not a signature by the Wallet Provider (WP) over a set of keys of which the WP declares that they are suitable to put in an credential. Instead it is its own credential (in JWT format), having its own public key like a credential always does, in a cnf header field.
> • During issuance of a set of credential copies, the wallet sends:
>     • the PoPs of the keys of the credential copies, as usual;
>     • the WTE and a PoP of the private key of the WTE;
>     • a PoA over the WTE key and the key of the PoP of the credential.
>
>
> From this, the issuer infers that the WTE and the credential key belong to one WSCD, which was apparently deemed trustworthy by the WTE issuer, so that it is issuing its credential to a trustworthy key. The advantages of this approach is that the wallet doesn't need explicit blessings of the WP over every single key that a credential is issued to, which should lessen load on the WP and increase user privacy.
>
> Currently, in our implementation a Credential Request looks like this. Please note that this is just an initial implementation that we made to have a starting point; it is by no means final, and indeed I am mailing largely to talk about what this should become instead.
>
> {
>   "format": "mso_mdoc",
>   "doctype": "com.example.pid",
>   "proof": {
>     "proof_type": "jwt",
>     "jwt": "eyJ0eXAiOiJvcGVuaWQ0dmNpLXByb29mK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiRldUZWtyTWNsRV9YSDM2aWl6QXlPQ0lpREI2LTNVOGd0QmxabFg5dmFjWSIsInkiOiJyNWlDZWFPTVJNRjBDY2ZMLUYyWkNqOUxkVHphcGlrWmxBQ3FyLTFUNUJjIn19.eyJpc3MiOiJodHRwczovL3dhbGxldC5lZGkucmlqa3NvdmVyaGVpZC5ubCIsImF1ZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWFuY2UvIiwibm9uY2UiOiJXMjJsVTY5a29LRlNINUZadW52ck5kanhqbndLRnQzVCIsImlhdCI6MTcyOTQzNzE1M30.4-sj7NyRqzEh4hPlSrhnf2HdkWzDrLJ33n9OCcjCV9GzMlC5ugCWcJ31Oa50E7kXysoL1CBqdmfdFFWbD31EWA"
>   },
>   "attestations": [ // The WTE and its PoP
>     "eyJ0eXAiOiJqd3QiLCJhbGciOiJFUzI1NiJ9.eyJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoibG5lbFBRaThNTVdxTXV3cE95MWloN2lsaDktV2xYVloya3U3Ri04SHRzRSIsInkiOiJkM3NBbG9nTVd4X2JvYmRCeGdLbmVkcGM5X0VlWFRBYTNOZkhyd1JOZWpNIn19LCJpc3MiOiJpc3MiLCJleHAiOjE3Mjk0MzcxNTN9.TAZKFgS_2Sqix0OplA62gZPP6I6bGHdudzBN6TXGxpSfhgFDONLnq8emNZ8-sIMm9N5lsRSdn-fp8S-UsmeCyg",
>     "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwczovL3dhbGxldC5lZGkucmlqa3NvdmVyaGVpZC5ubCIsImF1ZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWFuY2UvIiwibm9uY2UiOiJXMjJsVTY5a29LRlNINUZadW52ck5kanhqbndLRnQzVCIsImlhdCI6MTcyOTQzNzE1M30.UY3x-z9w5Ks6NhywHT8NJ76wHtleAMDfHs6sIJ-E6TIA7V-zkeS39iDsiPqXm9VnJBiY-anzTgL3I0Kl5Xjz5w"
>   ],
>   "poa": {
>     // as in the example above
>   }
> }
>
> WTE and PoA in OpenID4VCI
>
> The current key attestation PR, https://github.com/openid/OpenID4VCI/pull/389, offers two ways of including a key attestation:
>
> • It may be included in the JWT header when using the Credential Request jwt proof type,
> • Alternatively, a new attestation proof type may be used.
>
>
> Neither approaches seem suitable for our WTE and PoA, because:
>
> • In the first approach, we always have a single WTE and WTE PoP JWT and PoA, while a Credential Request may contain multiple jwt proofs;
> • The second approach misses a place for the WTE PoP JWT and the PoA. Additionally there is a semantic difference: a key attestation as defined in this PR (a signature over some keys) and a WTE (a credential) are very different things.
>
>
> Given that this PR works (at least in the second approach) by adding a Credential Request proof type, we might consider adding yet another proof type for this, perhaps called wte, looking like this:
>
> {
>   "proof_type": "wte",
>   "wte": {
>      "jwt": [
>        // PoPs as in the `jwt` proof type
>      ],
>      "wte": "<WTE JWT>",
>      "wte_pop": "<PoP of WTE key>",
>      "poa": {
>        // PoA as in the example above
>      }
>   }
> }
>
> Alternatively, we could stick to the jwt proof type and use https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/ for the WTE and its PoP, but then it seems a little strange to me that in that case the PoA would contain keys that are present in both the JSON body and a HTTP header of the HTTP request.
>
> Finally, I should note that we have multiple ideas on how to implement the PoA. There is also an approach differing from the one I showed above in that it involves zero-knowledge proofs. This approach has a number of advantages, but requires more cryptographic sophistication of the WSCD, so we decided to go with what I wrote above for now. However, to allow for potential future other approaches it is probably sensible to include some name or identifier in the poa field to identify the approach, like jwt and attestation (and perhaps wte) are identifiers for the proof type. The one I introduced above could then perhaps be called json_jwts. (But I am certainly open for suggestions concerning names.)
>
> I would very much like to learn what you think about this approach. I hope I have explained our situation understandably, but if not please don't hesitate to ask questions. Or perhaps I could join one of the WG calls so we could discuss it further there. Let me know what you think.
>
> Thank you, kind regards,
> Sietse Ringers.
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241204/f5375769/attachment-0001.htm>