[Openid-dcp] 11 Nov DCP WG notes

[Gareth Oliver]

Attendees

Gareth Oliver

Kristina Yasuda

hichamlozi

Michael Jones

Peter Sorotokin

Daniel Fett

Christian Bormann

Oliver Terbu

Paul Bastian

Tobias Looker (MATTR)

Stefan Charsley

Notes

   -

   Interop events, both openid ones, two over the next two weeks and ISO
   one in new zealand.
   -

   Number of calls; intending to reduce the number of calls. Poll in the
   next few days.
   -

   IETF:
   -

      Jose HPKE has a new still-in-draft in-process PR, as an alternative
      to OpenId4VP/OpenId4VCI defining its own wrapper.
      -

      Expected to be done in the next week or two
      -

      ClientAttestation: don’t say anything about ClientId.
      -

      sd-jwt-vc: A lot of work has been done but didn’t change that much.
      Suggested going to WGLC but still some push-back. So in pre-last call
      review cycles.
      -

         Request for folks to read it
         -

      Sd-jwt: In the RFC queue.
      -

      Cryptography: A lot of discussion on ZKP and cryptography. Some
      discussion on starting a more applied/engineering focused
cryptography. New
      mailing list started.
      -

         This is the new non-WG mailing list about ZKP
         https://mailman3.ietf.org/mailman3/lists/zip.ietf.org/
         -

         Notable usecase is reducing/remove batch issuance needed
         -

   HAIP PRs
   -

      Require x5c header across the specification for key discovery.
      -

      Missed when in appendix d key attestation format.
      -

         Comment that this could result in a lot of x5c headers, if doing a
         lot of key attestations.
         -

      PR defining ecosystem terminology
      -

         Editorial: do we need to capitalize Ecosystem? (yes)
         -

      PR First-pass re-adding ecosystem examples
      -

         Suggested compatibility rather than interop for the second example
         -

         Any opinions on x509
         -

         Look very specific, not very example-y.
         -

            This is the intent.
            -

            Some concerns raised because it might be considered to be a
            profile from HAIP.
            -

         Question on whether the verifier should support both
         -

         Noted that in EU issuer issues both
         -

         Updated to have verifier support all credential formats that a
         requested credential can be in.
         -

      A256GCM
      -

         ISO has A256GCM and A128GCM
         -

         Suggest mandate supporting both
         -

         Java Card doesn’t support A256 (if, for example, you have a chip
         that
         -

            A128 constant exists since 2.0.5 but requires platform support.
            -

         encrypts the response)
         -

            When does this matter
            -

            If the entire response is created in the secure element.
            -

         Could mandate this for the verifier.
         -

         How would they indicate? They can specify it in the request, and
         it comes back in the response.
         -

         Conclusion is to make the update for the Verifier to support
         either
         -

   Server-to-Server
   -

      Does this make high-level sense?
      -

         General consensus is yes
         -

      Can we delve into more details on how it would mechanically
      -

      One of the more complex question is how to manage encryption.
      -

         More finicky encrypting response back
         -

         Start conclusion is that where to place data is not negotiated so
         either sues a baseline from the protocol, or additional data
bilateral.
         -

      Chair to keep an unofficial slot for discussing server-to-server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20251113/879b60c3/attachment-0001.htm>