[Openid-specs-digital-credentials-protocols] DCP Call Notes 29-Aug-24

[Michael Jones]

DCP Call Notes 29-Aug-24

Joseph Heenan
Kristina Yasuda
Mike Jones
Giuseppe De Marco
George Fletcher
Steve Venema
Jin Wen
Brian Campbell
Paul Bastian
Christian Bormann
Daniel Fett
Jan Vereecken
David Chadwick
Ben Piercey
Martin Auer
Andreea Prian
Rajvardhan Deshmukh
Judith Kahrer
Bjorn Hjelm
Oliver Terbu
Hicham Lozi
Nemanja Patronogic
Martijn Haring
Torsten Lodderstedt
Sebastien Bahloul

Giuseppe presented about the Federation Wallet Architecture draft
                https://peppelinux.github.io/federation-wallet/main.html
                Call for adoption in progress in OpenID Connect working group
                Defines Entity Types for wallet entities
                                Credential Issuer, Wallet, Credential Verifier
                Depends on OpenID Federation, OpenID4VP, OpenID4VCI
                Four Party Model (Three from OpenID4VC + Trusted Third Party)
                Described possible work to do with DCP working group
                                Define jwks (JWK Set) metadata parameter
                                Define request_uris, response_uris_supported parameters
                                                Joseph had commented on endpoint randomization using fragments
                                Constrain Verifiers from over-asking
                                                presentation_definitions_supported to start discussion
                                Define OpenID Wallet Provider role
                                                Issues attestations about Wallet instances
                Giuseppe reminded the WG of the issue to incorporate Federation support in HAIP
                                https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/88
                Torsten asked about the Token Endpoint being used to issue wallet instance attestations
                                Giuseppe agreed that it's up to the working group
                                Torsten wants more implementation experience
                                Torsten wants us to keep differentiation between a reference design and specification we write to ensure interoperability
                                The interface between the wallet provider and wallet instance is internal

Oliver presented about the PR to address client_id_scheme problems
         https://github.com/openid/OpenID4VP/pull/237
                Mike, Brian, and Joseph agreed to review the PR

Joseph talked about PR to address issue 17 about client_metadata contents
         https://github.com/openid/OpenID4VP/pull/233
                Oliver pointed out that any jwks in the request must not be used to verify the signature
                                Oliver to supply text
                Martijn requested clarifications on parameters that MUST NOT be used
                                And where they may and may not be defined
                We discussed the jwks element
                                Brian suggested that we use the definition from RFC 7591 (OAuth Client Metadata)
                Brian said that multiple encryption keys could make sense but probably only one signing key
                Mike will review the language on extensibility

Kristina talked about the transaction data PR
         https://github.com/openid/OpenID4VP/pull/197
                Paul said that a cleaner separation would be a different credential format only used for transaction authorization
                Joseph asked: How does Paul's suggestion work - do you present a payment credential, then another credential alongside it that is linked to the payment credential and has the transactions details it, or we present the payment credential type and a transaction data like thing?
                Paul said that payment providers first validate the person, then issue a payment authorization token
                                The token is only shared between the issuer and the recipient
                Torsten said that we could create a new response type and credential format
                                That would be really clean
                What we have isn't as clean but Torsten is in favor of it
                Christian wants to clarify how to convey that the credential can be used for transaction authorization
                                Daniel agreed with that
                Torsten discussed clarifications about what can be signed and what can be used for payment authorization
                There was a lot of discussion about credential formats, including who can decide what formats to use and how they can be used
                There was a discussion of a two-party versus three-party model
                                The issuer and verifier could be the same party
                There was a discussion of how to include transaction data in the response in the issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240829/7a62745e/attachment-0001.html>