[Openid-specs-digital-credentials-protocols] 2024-01-31 SIOP/DCP APAC Call meeting notes

[Tobias Looker]

Apologies about the delay in getting these out, I had mailing list issues.

Date: 9am 31st January (NZT)

Attendees

- Torsten Lodderstedt
- Lukasz Jaromin
- Paul Templeman
- Kristina Yasuda
- Christian Bormann
- Tim Cappalli
- Dima Postnikov
- Daniel Fett
- David Chadwick
- Brian Campbell
- Bjorn Hjelm
- Matteo Marangoni
- Tom Jones
- Tobias Looker
- Joseph Heenan

OpenID4VCI

PR 238

Kristina: I can provide some context. Joseph has been confused about the meaning of the sentence `non-exhaustive list of the values defined by this specification` which he has suggested to modify, currently we need some more review. My point of view is that the current sentence conveys two main messages 1) the current specification defines some valid values here 2) The values are non exhaustive as in implementations are free to define more.

PR 235

Kristina: This is a normative change, we have two parameters now this PR aims to make it more obvious around what suites the issuer supports for signing a credential vs verify a PoP in a credential request.
Tobias: I'm supportive of this change.
Brian: How about proof_supported -> proof_types_supported.
Kristina: Yes I agree, someone already suggested this change on the PR.

*Kristina to make additional changes to the PR, which moves the algorithms for proof to the key proof types section.*

PR 187

Kristina: This PR adds initial privacy considerations, however I think there needs to be additional detail so I am preparing an additional PR which will be submitted before EOD PST.

OpenID4VP

PR 84

Oliver: This is a very small change which clarifies something that is likely already obviously to most implementations. There are already two or three approvals.
Torsten: Is there any urgency on this PR?
Oliver: I need it merged before the next ISO WG10 meeting on the 7th of Feb

Any other topics

Torsten: I have one other question about an issue you filed Oliver post the last IETF meeting about lazy RP verification for OpenID4VP
Oliver: Issue #65, so this is related to ISO and some of the WG members complained about OpenID4VP and would like it addressed in the second addition. I've tried to create a proposal.
Torsten: I think this one of the big changes we should discuss.
Oliver: The current problem is, if you have a non conformant verifier (lazy implementation) the wallet has no way to detect it is subject to a phishing attack in a same device flow. Maybe next WG call I can speak to it more.
Torsten: I suggest people take a look into the issue so we can discuss it more on a follow up WG call.
Kristina: Oliver can you make a sequence diagram
Oliver: Yes I can add one

Torsten: I would like to discuss PR 59 for OpenID4VP

Torsten: The problem with this current proposal is JAR doesn't allow there to be the request_uri parameter so do we consider a new parameter instead?
Brian: Considering you are adding this new parameter request_uri_mode instead you could just communicate the uri in a new parameter like post_request_uri instead of request_uri
Torsten: One benefit is that there is then a fall back approach in the event the wallet doesn't support POST mode to the request_uri
David: I think we should ask the editors of JAR why they disallowed this

*Lots of discussion on this topic about the trade offs of maintaining compatibility with JAR vs a new parameter/endpoint that supports POST*

Thanks,
[MATTR website]<https://mattr.global/>

Tobias Looker
MATTR
+64 273 780 461
tobias.looker at mattr.global<mailto:first.last at mattr.global>
[MATTR website]<https://mattr.global/>
[MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal>
[MATTR on Twitter]<https://twitter.com/mattrglobal>
[MATTR on Github]<https://github.com/mattrglobal>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it – please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22001 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 872 bytes
Desc: image002.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 528 bytes
Desc: image003.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 921 bytes
Desc: image004.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1045 bytes
Desc: image005.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240201/910bfc34/attachment-0009.png>