[Openid-specs-digital-credentials-protocols] DCP WG Hybrid Meeting 28th October 2024 - Minutes

[Joseph Heenan]

Thanks to Rajvardhan & Christian for taking the notes! Please reply to the list if there any additions/corrections.



Attendees:
Kristina Yasuda
Joseph Heenan
Torsten Lodderstedt
Paul Bastian
Mirko Mollik
Lukasz Jaromin
Pam
Christian Bormann
Hicham
Gareth
Tim Capelli
Lee Campbell
Sam Goto
Mike Jones
Giuseppe De Marco
John Bradley
Oliver Terbu
Naohiro Fujie
Shigeya Suzuki
Rajvardhan Deshmukh

Slides:

https://docs.google.com/presentation/d/16NbYuDOnugUmbia6rxcczqQPu-RpHljKyb7dL-wmVqM/edit#slide=id.p


EU sent a letter to OpenID Foundation to sync on the standards work and share what is important to them
EU Letter is not public yet, but chairs will try to make it open
OpenID4VP ID just started
OpenID4VCI ID to start soon
HAIP is also considered by EU and shall move forward

Letter from EU expressed in slides. Don't want to mislead so not sharing it now, will share soon.
Questions related to timeline would be good to address.

Timeline:
Early jan final votes for implementers draft
Aim for March for 1.0
MSP to next round of implementing acts

VP query language feedback from implementers.
Multi RP auth to be figured out.
HAIP required after VP and VCI, probably after march.


Purpose field is a better approach than just strings.

General cleanup before final, would encourage folks to open issues.

https://github.com/openid/OpenID4VCI/pull/389/files
Key attestation format interoperably.
Created by wallet backend and Issuer should understand.
Platform specific vs dependency on wallet backend.
Json not ideal, maybe CBOR for secure storage/enclave.
Updating the platform takes 5 years, and it would be good to use formats supported by secure enclave.
For remote key storage.
EU Issuer has resp. N.Amer Issuer doesn't trust the wallet, verifier has to look at how key were created and stored, how was it activated and does it follow issuer policies.
Support both platform vs interop, as we can see which picks up.
Current PR supports backend arch. Create new PR to support platform arch.

Proof of association issue to be opened by Giuseppe

Lee will open issue for platform based key attestations.

No mapping from credential to `key_storage_type` with finer granularity.
If you are using secure enclaves, per platform config has to be understood by the issuer. Platform specific config shouldn't be there for key_storage_type as it creeps in platform dependency.

Structure of attested key structure.
2 use cases:
1. attestation as proof
2. attestation as element
Ask from interested participants is to give examples for 3 proposal for these 2 use cases, with prose and cons and with recommendations.

https://github.com/openid/OpenID4VCI/pull/392
option 3 will break the existing implementation
scopes
when you lookup CI metadata for scope its not an additional step.

when scopes were used in the authorization response:
1. if AS is capable of returning credential_identifiers parameter in the token response, wallet MUST use that in the credential request.
2. if AS is NOT capable of returning credential_identifiers parameter in the token response, wallet MUST use credential_configuration_id in the credential request.

PR will be updated and would like feedback.

https://github.com/openid/OpenID4VCI/pull/405
Claims are used to request optional credentials.
Just keeping Claims in authz details and deleting from cred request solves the problem. Implementers (Pedro) Don't issue credentials if its not authorized.

https://github.com/openid/OpenID4VCI/issues/339
Short explanation that this feature helps certain deployment models and a follow-up discussion around whether or not that type of encryption is necessary. Several people share their opinion that there is interest in that feature.

https://github.com/openid/OpenID4VCI/issues/339
Makes sense to have e2e encryption for the issuance stage as well. Italy implementation has VP implemented e-2-e and were curious about having the same for VCI

https://github.com/openid/OpenID4VCI/issues/278 
Oliver explains that there are different types of credential versioning (different cases explained here https://github.com/openid/OpenID4VCI/issues/278#issuecomment-1972859857). The proposal is about extending credential response to include identifiers to identify these different versions and a new endpoint to check if new credentials are available. The current information that is provided seems to be not sufficient to cover all of the use-cases.

https://github.com/openid/OpenID4VP/issues/248:
Joseph explains that the question is how to convey trust from different ecosystems for a relying party? One option was to add different signatures for the different ecosystems. Another problem is that a lot of ecosystems also need their own specific requests like the real_id extension used in the US for mDL. Martijn asks for a clarification regarding the mDL comment as it works with the same request across ecosystems right now. Lee responds that there might be a problem where with the new query language you can request different credentials that might come from different ecosystems, so you would need different signatures. Hicham clarifies that there are different problems and the problem is that the relying party does not know the wallet and which trust ecosystems / mechanisms the wallet trusts. Given the option of several signatures increases the chances for a request to work for the wallet.
Torsten answers that you could send the same request with different signatures and it is more a question of duplication and efficiency. Another question is if you would really send the same request in the different ecosystems. Torsten states that he believes that we should not treat these problems as completely different problems, but the problem is not only about client authentication, but also about schemas and what values you are requesting. Lee answers that he gets the point of Torsten that this could be different top-level requests with different signatures, but there might be cases where you request documents from different trust frameworks in one request - which would need different trust frameworks. Torsten and Lee discuss whether this is about the relationship between wallet and RP, or issuer and RP. Lee states concerns that this model (wallet <-> RP) would not scale globally. Gareth agrees with the concerns and as a Relying Party I want to be able to make a request to a wallet that might hold credentials from different trust ecosystems. John states that we (or also the EU) created this problem ourselves by forcing the signature for that on the RP. Torsten clarifies that he sees 2 different problems here:
the RP registration that the EU is introducing
A wallet containing documents from different trust ecosystems
Hicham states that multiple requests would be a solution but might be weird because the requests might be different. He states that the better approach would be one request with multiple signatures. Tom explains that this was already solved in Australia and is solved by accepting the VICAL. John answers that the verifier is validating the issuer, but the wallet is not validating the verifier and once we have wallets that are validating the verifier, we need a solution for something that spans multiple trust frameworks.
Lee concludes that it boils down to 2 questions: 
Will we have wallets containing credentials from different trust frameworks
Will we have requests that request credentials from different trust frameworks
Torsten agrees that this is different from his initial understanding and asks if you would need a combined query within one request which Lee agrees on.
John agrees that there might be quite a few use-cases that require you to sign a request with several signatures from different trust ecosystems.
Guiseppe sums up that we agreed on the what (the requirements), but are not clear yet on the how. Torsten sums up that we are talking about a use-case where a request contains more than one credential like a US mDL and a European PID where you would need to authenticate the RP in more than one context (trust framework). Martijn clarifies that we need a single double query to be signed with multiple trust frameworks.
David states that if we have the situation where credentials were issued under different trust frameworks and asks why the wallet would need to trust the RP under both trust frameworks, one trust framework should be sufficient. Lee replies that there are different trust relationships to different issuers and the trust needs to be established in every trust ecosystem.
Kristina summarises that we seem to have agreement on the problem statement and asks to focus on this issue and create proposals for this problem statement.

https://github.com/openid/OpenID4VP/issues/141:
Christian states that there was rough consensus to start with the wallet attestation as a credential conveyed normally in the query and vp_token. Paul states that he thinks it should be handled differently.
Lee asks why the issuer or an attribute in the credential wouldn’t be enough. Lee challenges if we really need a new credential.
Kristina asks people to differentiate between request and presentation. Martijn states that he is strongly against putting something special into the request and response.

Kristina asks to document sessions happening at IIW, so it can be used as input for the DCP WG.
There is a document to better align with the requirements of the ISO WG.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241029/48c6a602/attachment-0001.htm>