[Openid-specs-digital-credentials-protocols] 23/04/2024 DCP call meeting notes

Wed Apr 24 16:59:38 UTC 2024

Call notes for DCP WG 23st April 9pm CEST

Attendees

Sebastien Bahloul
Tim Capalli
Brian Campbell
Gabe
Elizabeth Garber
Joseph Heenan
Lukasz Jaromin
Michael Jones
Tom Jones
Torsten Lodderstedt
Gareth Oliver
Sudesha Shetty
Jan Vereecken
David Waite
Jin Wen

Joseph: A couple of regular attendees are excused (Kristina, Tobias, …).

Introduction of new people on the call:
- Gareth Oliver (Google)
- Elizabeth Garber (OpenID Foundation)

Main topic on the agenda: Debrief from OAuth Security WG (OSW) and Internet Identity Workshop (IIW)
(we didn’t really talk about OSW explicitly - everything that was discussed at OSW ended up also being discussed further at IIW)

But first, discussion on https://github.com/openid/OpenID4VP/issues/144#<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VP/issues/144*__;Iw!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxaL4xdL0g$>

Michael: Kristina has put a note (https://github.com/openid/OpenID4VP/issues/144#issuecomment-2067045699<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VP/issues/144*issuecomment-2067045699__;Iw!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxb9vqd2sA$>) to get feedback within a week but some of the requirements in the Google Document (best guess considering that the google docs is the superset of the requirements from the slides discussed in IIW), it would be considered consensual. Problem is that some the requirements are ambiguous / unclear. And now there comments on issue and on the Google Doc. So Torsten will liaise with Kristina to have a consolidated version between the issue and the doc in order to have further comments on the document only.

Tom: the following requirement is confusing “Verifier is able to request any credential format. ie CBOR and JSON”. Discussion between Torsten, Tom and Brian with a shared agreement that the underlying statement for this requirement is that the presentation format depends on the credential format (typically JSON Path does not work for CBOR)

Debrief from IIW on browser API

Torsten: Most of the time was spent on Browser API, so that it can work with OpenID4VP.
A couple of sessions with browser vendors and other active contributors.
Super impressive cross-device demo with a credential presented on a Chromebook initiating a wallet presentment on an iPhone through BLE based CTAP flow
Work through the proposal in PR 155 and cover it completely (even simplified).
Most important changes related to when the security model is not WebPKI
Agreement from browser vendors to move forward with this proposal.

Question on why multiple expected origins
Torsten: Depending on the architecture, one service could serve different web servers so having only one origin could make the integration more complicated

Debrief from IIW on PE simplification

Torsten: presentation link available on this comment https://github.com/openid/OpenID4VP/issues/144#issuecomment-2066939189
Good propositions but not a definitive answer: what is reported is the result of the discussions with the browser vendors, Kristina, Oliver, Niels … Goal was to keep the PE to some extent, but also allow to have format specific queries.
 Gabe:  PE should now be processed through the DCP group starting from now.

Additional topics from IIW

  *   Encryption:

     *   Sebastien: is Encryption of the request still in the picture. Torsten: No good way to deal with it, so out of scope for now
     *   Question on the needs for request encryption. Torsten: it could come when the credential request includes filters based PII.
     *   Torsten: You need to trust the OS anyway so as long as multi device data transfer is encrypted, it should be ok  (Tim: cross device encryption is part of CTAP)

  *   The batch issuance of multiple instances of a credential

     *   Two options: batch credential or credential request extension, decision to go with credential request extension
     *   Question: within the scope of the interop and/or the hackaton ? Torsten: Undecided

  *   Call to move OpenID4VCI from Connect ID to DCP, closes in a week, already a good amount of feedback, more are welcome.

  *   Deferred Authorization (https://github.com/openid/OpenID4VCI/issues/60<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VCI/issues/60__;!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxZt0pKeeg$>): current consensus is to remove it because there is no use case (unless anybody has a use case, in that case please comment on the issue).

  *   Leverage PE for authorize transactions (https://github.com/openid/OpenID4VP/issues/156<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VP/issues/156__;!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxZIm5Quxw$> ). One of the EU LSP has a use case and want to leverage OpenID4VP and typed transaction data to a request : user consent screen, show the transaction data include it in the signature. Payment was well received by one browser vendor representative as it seems to solve a quite complicated problem discussed on Web Payments

Tim: Webauthn have a similar concept (transaction confirmation), it would benefit to be aligned with this proposition as it is also in the scope of WebAuthn.
Torsten: The use case is a bit different because with OpenID4VP there is no need to have a key specific for the RP (unlike FIDO WebAuthn)
Tim: The thought was to try and align inputs.

Jin: There is also an earlier FIDO spec like FIDO UAF for transaction confirmation, please refer tohttps://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-protocol-v1.2-ps-20201020.html#transaction-confirmation<https://urldefense.com/v3/__https:/fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-protocol-v1.2-ps-20201020.html*transaction-confirmation__;Iw!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxZy22pwhQ$>

Other topics

  *   Proposal to delay a bit OpenID4VP Implementers Draft #3: once PE simplification and the client_id security issue are solved (initial motivation was to get it into the ISO draft but it is not anymore a strong motivation - so ID#3 could be delayed a bit). No comment on the call, proposal agreed.
  *   Feedback welcome on :

     *   Credential format request vs metadata: https://github.com/openid/OpenID4VP/issues/136<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VP/issues/136__;!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxbqN2ZnCg$>
     *   OpenID4VCI simplification proposal by Paul https://github.com/openid/OpenID4VCI/issues/294<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VCI/issues/294__;!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxaoYNUAKw$>
     *   How to reduce pulling from the wallet by adding a Shared Signal like approachhttps://github.com/openid/OpenID4VCI/issues/300<https://urldefense.com/v3/__https:/github.com/openid/OpenID4VCI/issues/300__;!!FZtbJVnXfw!xY7XyP3EfK4Low6xdcHabj4YZizoYLhjpkmbo9F7jBdfW_Yz5eKmdmb4YUNQaYzGY45ed_IuDWKkYxZS1rxSpQ$>

Thanks,
Sebastien
--
Sebastien BAHLOUL
Architect @ Products and Standards
Civil & Digital Identity
M +33 7 60 76 92 04<tel:+33760769204>
E sebastien.bahloul at idemia.com<mailto:sebastien.bahloul at idemia.com>
2 Place Samuel de Champlain
92400 Courbevoie
France
https://www.idemia.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240424/b576297b/attachment-0001.html>