<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">DCP Working Group Call 29-May-25<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Christian Bormann<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Joseph Heenan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Mike Jones<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Kristina Yasuda<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Brian Campbell<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Gareth Oliver<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Lee Campbell<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">John Bradley<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Oriol Canadéz Díez<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Tim Cappalli<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Peter Sorotokin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jan Vereecken<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Rajvardhan Deshmukh<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Filip Skokan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VP #598 - Implement signature verification requirements<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Waiting for feedback from Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VP #597 - Add encryption details parameter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - It's odd that we would be defining profiles but not using them<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - Made a remark about defining a default profile<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - Are we actually defining a profile here, or is HAIP the profile?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Commented that when using mDOCs, she would use mDOC values<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - We do need a name. What should we call it?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Mike - Is this for 1.0, which is in final review, or for 1.1?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - 1.0<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brian in the chat - We should not define a non-interoperable extension point for a problem we don't have<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Wrote a comment in the PR about apu and apv values<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - Summarized that there's a desire in the future to be able to encrypt in different ways<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> It would let implementations indicate profiles to be used in the future<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> There isn't wallet metadata at the time the request is being made<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - This is for fine-tuning how to use JWE<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - What the receiver supports needs to be known to the sender<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lee - Why are we doing this at all? Why not just define it?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Does anyone need the additional profiling?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> This seems to lead to more fragmentation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - You're recommending fully-specified encryption schemes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lee - Is this really about apu and apv values or is there more to it than that?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - Some people are asking for the detached mode<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> This is a way to indicate things like that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brian - There are breaking changes caused by the extension point and varying levels of support<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Encryption already works<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lee - This feels messy - we'd have to carry this burden forever<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Why not figure this out in advance<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Lee and Brian, please make comments in the PR<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VP #610 - Add session transcription for redirect-based flow<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - Are we intending to never support it?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - The use case for multi-RPs is understood<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> It would be good to clarify the expectation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - Our security architecture relies on Client ID<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> I would be reluctant to remove it at the last minute<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - The trust framework needs to be able to support a single identifier belonging to multiple trust frameworks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Multi-RP may be trying to solve the problem the wrong way<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - I think we don't have a solution<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Asked for volunteers for a related Implementation Considerations PR<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth volunteered<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Asked for objections to merging<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Someone pointed out that ISO was asked to review<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> We should give them at least a day to do so<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - We got objections about the same Client ID thing<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - That was me<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> It may have also been Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Please re-review<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Otherwise, Kristina plans to merge tomorrow night<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VP #615 - Transaction data hashes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - There is a potential interop issue<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - There are questions about doing the hash over base64url-decoded data<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - This hasn't been discussed on a WG call<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> People may need more time to look at the issue<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VP #509 - Privacy Considerations<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Nat added content<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lee - I can go through this offline<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VCI<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> We don't have any issues that are awaiting PRs<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VCI #527 - .well-known syntax<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Joseph - Proposes changing from Connect syntax to IETF syntax<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - I don't think we have much of a choice<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - This is unfortunate, but probably inevitable<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Having two ways to do it is worse<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> The keep-off-my-lawn advocates are clear<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - I don't hear objections for moving in this direction<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - We should probably wait a week<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - No, because we're coming up to WGLC, we're not waiting a week<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Once we have enough approvals, we're golden<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OpenID4VCI #522 - Integrity of JWK used for Credential Response encryption<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - Would be good to have someone familiar with LDP review<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - We investigated multiple options<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Decided to have an extra parameter to carry the encryption key<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Decided not to bind it to the use of DPoP<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lee - Why do we need this at all?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> We're already using TLS. What are we worried about?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - Prevents decryption by TLS middle parties<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - Are onboard with this approach or do we want to consider the DPoP approach?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - Having to define how to provide a key for every proof type is problematic<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> There's an elegance to doing whole request signing<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Then it's just a question of how to choose the signing key<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - We don't have a key that is mandatory for the wallet<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - You can only have integrity-protected encryption if you sign the request<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Gareth - Friction caused by differences are problematic<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> We plan to go the DPoP route<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - The best practice would be to integrity protect the credential request<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> I don't think we've properly thought through all the things in a request that would be useful to attackers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Integrity protecting the request is a natural complement to encrypting the response<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - I've been trying to avoid coupling features<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - I think it's reasonable to tie these together<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> If the attacker can change the encryption key in the request, we haven't achieved anything<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Having an integrity-protected request is reasonable<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - Do we need a second PR?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> We have two options - Wallet attestation and DPoP<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - Those are the only two keys I'm aware of<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Christian - We would need a way to signal which to use<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> John - The attestation key may not be a key that the wallet has access to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> The key that the attestation is over is available to the wallet<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Kristina - We need more discussion on this<o:p></o:p></span></p>
</div>
</body>
</html>