[Openid-dcp] 10/05 DCP WG Notes

Gareth Oliver gco at google.com
Thu May 22 15:14:48 UTC 2025


Gareth Oliver

Kristina Yasuda

Joseph Heenan (OIDF & Authlete)

Mastercard: robert gallagher

David Kelts

Christian Bormann

Steve Venema

Oliver Terbu

Brian Campbell

Ryan Watkins (Mastercard)

Paul bastion

Daniel Fett


   -

   VCI Issues
   -

      510 - Asking if batch size issuer metadata should be per-credential
      -

         The current suggestion is don’t do anything as it is the maximum.
         -

         Batch size is maximum in a request, so you can always ask for
         more.
         -

         Various assumptions at play here.
         -

         Some discussion about about revocation but outside of scope.
         -

      506 - deferred credential endpoint encryption
      -

         Response encryption keys? Yes/Maybe.
         -

            Mandatory to include (but not necessarily regenerate)
            -

         Same issuer metadata? Yes
         -

         Allow credential request encryption
         -

            Yes for symmetry
            -

         Gco to write the PR
         -

      494 - Should vs Must for credential_signing_alg_values. MUST seems
      good
      -

      497 - proof_signing_alg_values_supported is not defined for
      attestation proof type. Should do that.
      -

      499 - proof_signing_alg_values_supported doesn’t say must be one of
      the supported ones, but clearly should be.
      -

      376 - Issuer metadata is optional. What should I do if it isn’t
      there? Display nothing, or do whatever, or require it.
      -

         Should it be a should or must?
         -

         Device has a lot of context. Wallet should communicate with the
         Issuer to display it, but it may not be the perfect information.
         -

         Should it be a should or a may?
         -

            Do we even have a recommendation?
            -

            Doesn’t seem to (except for a non-normative should)
            -

            Resolution no-action and clarify
            -

      480 - Need to add support for compression. Otherwise closing as not
      needed.
      -

      226 - Integrity of jwk
      -

         If we can trust TLS, it’s not a problem.
         -

         Is this snowballing out of control?
         -

         Should we remove all of credential response encryption
         -

         What do we do if we don’t have dpop
         -

         Allow signing in vci then can specify it more precisely elsewhere.
         -

         Other option tying encryption keys to other keys can be
         authenticated.
         -

         Still tbd on final decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250522/90918ca6/attachment-0001.htm>


More information about the Openid-specs-digital-credentials-protocols mailing list