[Openid-specs-digital-credentials-protocols] Minutes DCP/SIOP meeting 09-21-2023
torsten at lodderstedt.net
torsten at lodderstedt.net
Fri Sep 22 17:58:31 UTC 2023
Hi all,
please find the meeting minutes below.
@David Chadwick: thanks for taking notes.
best regards,
Torsten.
Present:
Torsten Lodderstedt(Chair)
David Chadwick (Notes)
Pedro Felix
Andrew Hughes
Mike Jones
Naohiro Fujie
Daniel Fett
Bjorn Hjelm
Judith Kahrer
Mattia Zago
Amir Sharif
Rajvardhan Deshmukh
Sudesh Shetty
Lexi Ashpole
Matteo Midena
David Waite
Brian Campbell
Nick Burgess
Paul Bastian
Venk (??)
Gail Hodges
External Events
There will be a face to face on the 9th of Oct at 9am in Mountain View. Remote participation is also possible.
Agenda Topics
Security draft
Daniel: The idea is to take a broader view than in the security consideration section of the spec.
Verifier has to trust the wallet. User also has to trust the verifier.
If it only concerns one protocol then it can move to
This doc has not yet been accepted by the group.
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.
Wallet attestations and nonces
Issue 71
https://github.com/openid/OpenID4VCI/issues/71
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.
Paul: Can use preauthorised code as a nonce. This would save a round trip.
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.
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.
Torsten: Having authn at the token endpoint only introduces asymmetry. Authn is already at the PAR endpoint. Paul questioned why authn is needed twice.
Significant amount of discussion back and forth. Torsten asked people to add their comments to the issue so that they are recorded.
PR 65 add identifiers for issuing credential of the same type, different content
https://github.com/openid/OpenID4VCI/pull/65
Please add your comments to this issue
Issue 45 Advanced flow for OpenID4VP
https://github.com/openid/OpenID4VP/issues/45
Torsten asked if pull request could be started to address this issue. No objections to the PR being created
PR 44 on OpenID4VP about PD by ref
https://github.com/openid/OpenID4VP/pull/44
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20230922/d6434723/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list