-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issuer Trust Evidence / key attestations for OpenID4VCI #355
Comments
Hi @paulbastian To my understanding with your proposal
If so, I think there is the following practical problem: |
I think this issue is about different things:
I think the issuer trust evidence (3) could be provided as part of the proof. I'm thinking of an additional JOSE header, just like x5c. |
After the discussion in the WG meeting on Tue, I have come to the following conclusions: I think it suffices to add a new header
The The attestation could:
(1) would allow to migrate existing code using the "old" wallet attestations to be used at the credential endpoint and would allow a simple model for issuing individual credentials. There is also a possible extension: there is a concept called "Proof of Association" being discussed in the EUDI Wallet space. It allows to proof that two keys are managed by the same security module (aka WSCD). The issuance flow could utilize this concept to minimize the data shared with the wallet backend (privacy) and reduce the calls needed to create key attestations (performance, availability). The wallet app would obtain one attestation for a key serving as trust anchor (Issuer Trust Evidence). Subsequently, the wallet app could create a new key in the local WSCD along with a proof of possession between the ITE key and the new key. This would basically be a static assertion and could be treated as part of a chain of trust. That's why I think it could just be added to the attestation header as another JWT. The trust would then be from the ITE via the PoA to the PoP for the new key. |
discussed in the WG during the calls in the week of july 15th. as the next steps, there seems to be rough consensus on the following points (from Torsten's earlier comment):
Agree to focus discussion in this issue on open a new issue to discuss |
to elaborate in a bit more layman terms what has been discussed/proposed on the call for point 3: a. there is device key A to which wallet instance wants an issued credential to be bound |
How this maps to today's x509 issued by QTSPs? Such mechanisms do exist today in the x509 world. |
@tlodderstedt where should the WTE be presented to an issuer as part of the request to get another attestation like a Diploma?
|
ARF in annex 1, provides the following short definition
So, I guess that it is WIA that will be presented to the token / PAR endpoint of the For WTE there is the following
Also in annex 2 there are several WTE related requirements. Notably WTE-25:
My understanding is that the present issue discusses the options to implement this requirement. That is, WTE is presented somehow to Credential Issuer Endpoint. |
Hello all, I have listed a few requirements that are important for us in the EAA issuance process:
WSCDInfo contains:
KeyInfo contains: |
@alenhorvat I have never seen key attestations in the QTSP context. Can you please refer to solutions for this problem in the x.509 world? |
@ssanchocanela WTE/ITEs shall be presented with the credential request (at the issuer). The WIA shall be presented to the AS with the token request. |
@andprian thanks a lot! |
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. In other words: x509 cert is a public key attestation :) And they are used quite frequently today. |
You can, of course, express it in different formats. Here we mapped the eidas v1 x509 cert to a W3C VC data model: |
split the discussion about the optimization to #368 |
@alenhorvat this issue is about key attestations. My question was: Where QTSPs use key attestations today? |
Summary: after we have split the optimization from this issue, the focus is on
|
Example of a simple, interoperable key attestation that would go into a new header
|
Paul and Torsten agreed on this proposal to add the key attestation to the existing JWT proof type:
For the CWT proof type, we could add a similar COSE header. |
for CWT, we should first discuss if we are removing it or not #341 what we have in HAIP now: https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-4.3.1-3.1.1 @F-Node-Karlsruhe @dlongley do you need a mechanism for key attestation that is being discussed in this issue for ldp_vc proof type as well? |
in the wg call, agreed to do two PRs
|
Hmm, I would expect that either the mechanisms being discussed here could be used even if the issued credentials use the (But, admittedly, I may be missing an important detail for why this approach would not work.) |
@tlodderstedt, I added my comments on PoP keeping in mind that the Credential endpoint will be used for issuing multiple EAA at once and as a reaction to the discussions on this issue that we might not do PoP for all keys. As long as we always keep the possibility to transmit PoP for all private keys associated with EAA, that is ok with me. For the examples, yes, the Issuer should state what LoA he expects to be reached. But the Issuer also bears a responsability on enforcing the LoA High requirements, especially a PID Provider. He has to make sure the Wallet Instance allows to reach for this level, hence the details he has to receive on the WSCD. If a Wallet supports multiple WSCDs, that could appear in one single ITE listing all the details, while the KeyInfo would reflect what WSCD exactly hosts that specific key. The key lifetime is a way to specify extra constraints that might reduce the validity of the EAA that was initially forseen by the Issuer. The authentication methods are crucial for the key protection. Just to give an example, in France we would not be able to pass certifications if we protect something sensitive with an OTP send via SMS, so it is important that a PID Provider has a say in what authentication factors he accepts. |
@dlongley what is a mechanism in ldp_vc that is equivalent to a JWT header? I think all we need to say is that for ldp_vc, put key attestation there. |
If I'm understanding correctly, this would be for the And, if I've got that right, what can be said is that the key attestation is to be provided as (or within) a VC that is itself within the VP that is signed by the holder (using said key). |
when there is attestation for only one key, isn't it an option to use platform-specific key attestation (like Android Keystore Key Attestation) here? |
We are considering to obtain the attestation from Google/Apple as first step when you download the wallet, then present the that attestation as part of the activation process to get the WTE. |
I think it's a bad idea, issuers will end up requiring to understand many different attestation formats. These formats will change over time. It's a complexity that many issuers may not be able to handle. That's why wallet provider shall handle those platform specific attestations and issue ITE |
It is the wallet provider the one the shall verify that attestation from Google or Apple. The attestation can be sent within the proof on the idToken. |
In the context of eIDAS 2, we require a Wallet/Issuer Trust Evidence, basically a key attestation made by the Wallet Provider ensuring that keys used for keybinding really reside in a trustworthy key store (called WSCD in eIDAS). In earlier iterations the construct that has so far been called "Wallet Attestation", consisted of two statements:
After disussions at EIC 2024, we propose to split this up and match with current eIDAS directions, i.e. have two attestations:
The WIA could be tested with Attestation-Based Client Authentication at the PAR or Token Endpoint. What's remaining then is to convey and integrate the ITE/WTE concept to OpenID4VCI.
The proposal is to send the ITE/WTE at the Credential Endpoint, because this is where the keys are transmitted. The easiest and least breaking possibility is to create a new proof type, this could potentially also address other issues like #305 which increase the scalability of batch issuance.
The diagram gives a rough idea:
Diagram
A new proof type could like this:
The ITE may include device_keys public key array that the Credential Issuer could trust directly without additional PoPs. The ITE may also include status information to communicate possible WSCD compromise.
Lets start the discussion :)
The text was updated successfully, but these errors were encountered: