
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">

<div dir="auto">Announcements:<br />

Oliver Terbu: Spruce is organising an event around ISO 18013-7 https://spruceid.com/iso-mdl-interop-event (info-session Jul 14th). Async fully-remote event over two weeks.<br />

Torsten: Felix has attended some calls and worked on bluetooth spec and want to share the results. Next week we will probably hear more about that.<br />

<br />

Nander: Question about adding a parameter to the (verifier's) client_metadata that lists potential credential issuers where the Wallet can acquire a required credential if it does not possesses it yet.<br />

Torsten: We have been thinking of that but makes more sense to add this to the presentation request. Torsten sees value in it --> open an Issue with a suggested solution for this.<br />

<br />

PRs<br />

#524: https://bitbucket.org/openid/connect/pull-requests/524<br />

Basically 1 question: whether there's data in the attestation that tells the wallet when the jwt starts to be valid. Discussion is already ongoing on BB (BitBucket).<br />

Suggestion to make the `nbf` required --> when does the attestation starts to be valid. Alternative would be `iat` --> Which one should we use?<br />

discussion about whether`nbf` is only for future-dating tokens.<br />

"None of the specs make `nbf` REQUIRED"<br />

Michael: `iat` should be REQUIRED + probably better to mention `nbf` at all.<br />

Conclusion: Still a draw<br />

Torsten: Suggests to still merge this PR, and continue the discussion in a new Issue.<br />

<br />

#551:<br />

We need more reviews and approvals from people in this call (either comment or approve this PR).<br />

<br />

#542:<br />

PR seems to be good to go, but more approvals are much appreciated.<br />

<br />

#535:<br />

Seems to be good to go as well, so will be merged after this meeting if there are no objections (no objections)<br />

<br />

#557:<br />

Oliver: Conversation about encryption of the credential response. Basically, having client_metadata(_uri) as optional parameter in credential request.<br />

PR also introduces a mechanism to negotiate the cypher suite to be used.<br />

The reason for this PR is that this is a requirement by certain communities. They have a need for app-level encryption.<br />

Important!: No further questions, so please approve (and/or leave comments)<br />

<br />

Issues:<br />

#1951: https://bitbucket.org/openid/connect/issues/1951/direct_post-response-mode-response-with-a<br />

Discussion about the sequence diagram (https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_post-2). Question about whether the diagram would work in the cross-device scenario --> the sequence is designed for the same-device scenario.<br />

Move the discussion to the issue. Pedro will add an additional comment to the Issue.<br />

<br />

#1922 + #1923:<br />

Boils down to: we need identifiers for multiple issuance of credentials.<br />

The question is: Do we need a dynamic solution for this, if so, how to go about it?<br />

Please review! These issues have the potential to be a significant addition.</div>

</div>

</body>

</html>