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

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">

<div dir="auto">Hi all, <br />

<br />

please find the meeting minutes below. <br />

<br />

@David Chadwick: thanks for taking notes. <br />

<br />

best regards,<br />

Torsten. <br />

<br />

Present:<br />

Torsten Lodderstedt(Chair)<br />

David Chadwick (Notes)<br />

Pedro Felix<br />

Andrew Hughes<br />

Mike Jones<br />

Naohiro Fujie<br />

Daniel Fett<br />

Bjorn Hjelm<br />

Judith Kahrer<br />

Mattia Zago<br />

Amir Sharif<br />

Rajvardhan Deshmukh<br />

Sudesh Shetty<br />

Lexi Ashpole<br />

Matteo Midena<br />

David Waite<br />

Brian Campbell<br />

Nick Burgess<br />

Paul Bastian<br />

Venk (??)<br />

Gail Hodges<br />

<br />

External Events<br />

There will be a face to face on the 9th of Oct at 9am in Mountain View. Remote participation is also possible.<br />

<br />

Agenda Topics<br />

<br />

Security draft<br />

Daniel: The idea is to take a broader view than in the security consideration section of the spec.<br />

Verifier has to trust the wallet. User also has to trust the verifier.<br />

If it only concerns one protocol then it can move to<br />

This doc has not yet been accepted by the group.<br />

Torsten asked if anyone objects to this. Otherwise he will mail the list asking for the doc to be accepted by the group as a working group draft.<br />

<br />

Wallet attestations and nonces<br />

Issue 71<br />

<a href="https://github.com/openid/OpenID4VCI/issues/71" target="_blank">https://github.com/openid/OpenID4VCI/issues/71</a><br />

Torsten: Proposal is for Wallet to request a nonce from the Issuer to stop the attestation being replaced. Nonce would be instead of jti. Could follow DPOP approach. If nonce is missing, attestation is invalid. Alternative is error response model. If POP request is cheap then wallet can request nonce in first message exchange.<br />

Paul: Can use preauthorised code as a nonce. This would save a round trip. <br />

Daniel said it might be sufficient to protect the token endpoint with the wallet attestation. The token endpoint is close to the artifact being protected, so that would be a good match.<br />

Using attestation at the token endpoint but not PAR will mean: Either the wallet attestation is not a client auth method any longer — or we risk introducing inconsistencies (that we would probably regret). Using attestation for the PAR means that the request was created by an attested party; it does not mean that at that moment I'm talking to the correct party.<br />

Torsten: Having authn at the token endpoint only introduces asymmetry. Authn is already at the PAR endpoint. Paul questioned why authn is needed twice.<br />

Significant amount of discussion back and forth. Torsten asked people to add their comments to the issue so that they are recorded.<br />

<br />

PR 65 add identifiers for issuing credential of the same type, different content<br />

<a href="https://github.com/openid/OpenID4VCI/pull/65" target="_blank">https://github.com/openid/OpenID4VCI/pull/65</a><br />

Please add your comments to this issue<br />

<br />

Issue 45 Advanced flow for OpenID4VP<br />

<a href="https://github.com/openid/OpenID4VP/issues/45" target="_blank">https://github.com/openid/OpenID4VP/issues/45</a><br />

Torsten asked if pull request could be started to address this issue. No objections to the PR being created<br />

<br />

PR 44 on OpenID4VP about PD by ref<br />

<a href="https://github.com/openid/OpenID4VP/pull/44" target="_blank">https://github.com/openid/OpenID4VP/pull/44</a><br />

One solution is to sign the PD, so that you know it is trusted. Another way is to use a trusted public policy server that returns the unsigned PD. Giuseppe suggested using the scope parameter to specify the PD.<br />

<br />

<br />

<br />

<br /></div>

</div>

</body>

</html>