[Openid-specs-digital-credentials-protocols] 03/25 DCP WG Notes

[Gareth Oliver]

Participants

Gareth Oliver

Kristina Yasuda

Torsten Lodderstedt

Gail Hodges

John Bradley

 Timo

 Christian Bormann

 Paul Bastian

 Oliver Terbu

 Daniel Fett

 Martijn

 Rajvardhan Deshmukh (Cisco)

 Ryan Galluzzo, NIST ACD

 Steve Venema

 Michael Jones

 Tobias Looker (MATTR)

 Bjorn Hjelm

 Peter Sorotokin

Stefan Charsley

David Zeuthen (Google LLC)

Andres Olave


   -

   Finish PR today
   -

   Doing Transaction data thursday
   -

   ClientId scheme PR issues
   -

   Register for Pre/Post IIW WG
   -

      Time changed for Post
      -

   Vote for HAIP implementor’s draft going on
   -

      https://openid.net/foundation/members/polls/355
      -

   Doodle for japan et al friendly meeting to come out soon
   -

   Review PRs
   -

      Clarify Value Matching. No more comments.
      -

      Adding public key to session transcript. Clarifying text then will go
      in.
      -

      Security considerations for DCQL going in
      -

      Request not to open PRs for issues that aren’t ‘ready for PR’
      -

      Some editorial improvements regarding DC API should be mergable
      without discussion
      -

      Making claim_set ordering recommended instead of mandatory going in
      -

      Multi-RP Credential/Authentication capabilities. Removing client_id
      solved this.
      -

         Do we need to check it? I.e. if there is an error should we reject
         -

         This doesn’t change anything.
         -

         Is it that we expect that a wallet can ignore it?
         -

         Change DC API so origin is the basic security mechanism.
         -

      Transaction Data [To be talked about on thursday]
      -
      -

   Ready For PR issues
   -

      How to do value matching for mdocs: to be clarified by zeuthen
      -

      Clarify key selection
      -

   PR Discussions
   -

      Discussion on removing JARM
      -

         Moving to only allowing unsigned encrypted JWT
         -

         Label ready to PR -> assigned to gco
         -

      Behavior with multiple and transaction data
      -

         Maybe you could want to sign the same data with multiple payments
         -

         Should we restrict it? Better to be permissive. Let it be defined
         by the transaction type
         -

         Can it be punted to 1.1? No because it is a breaking change.
         -

         Discuss further on thursday
         -

      Presenting VC without a VP
      -

         We should include nonce and aud
         -

         Not relevant if we present it with a bound one
         -

         Why is ‘state’ not as good as nonce. OAuth world has moved away
         from it. Technically the same.
         -

         Only get it if you have no keybound credential
         -

         Nonce has to be cryptographically secure but state doesn’t have to
         -

         Don’t need it for DC API
         -

         State vs Nonce: using nonce seems to overload it. State is also
         overloaded.
         -

         Worried about using DC API for something that could be replayed.
         Can we say for 1.0 require the credential, and 1.1 revisited.
         -

            +1’d as it (nonce) appears in two places.
            -

         Suggestion: if only a non-key bound credential is sent, nonce must
         be sent in as in option B2.
         -

            Dangerous to send nonce by itself (as it might mean something).
            -

            Same true for B1 and B2
            -

            State would make more happy
            -

         DC API - No Change
         -

         Non-DC API -   Recommended return with a key-bound credential,
         else return State
         -

   Optional Mdoc fields: Should they be mandatory?
   -

      Yes doctype_value, and vct_values
      -

      Cuts out usecase ‘I want X from any doctype’
      -

         Seems ok as doctype is necessary to understand the context of the
         document
         -

      Should we allow self-attested data
      -

   PE or not to PE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250327/ba4191e9/attachment-0001.htm>