[Openid-specs-digital-credentials-protocols] OIDF DCP WG meeting notes for 2024-07-16 APAC Friendly Call

[Tobias Looker]

# Attendees

Joseph
Torsten
Kristina
Oliver
Rajvardhan
Mike
Sudesha
Tim
Daniel
Brian
Hicham
Bjorn
Nemanja
Christian

# Events and External Orgs

Joseph: Gail sent an email to the list about a Cali DMV hackathon on the Friday after IIW, in Sacramento. Please review the email and ask questions.

Joseph: Related to that we are planning to have another hybrid in-person WG meeting around IIW, still looking at slots that are suitable, potentially Monday morning.

# Issues (OpenID4VP)

## Issue #211, co-existence of multiple query languages.

Joseph: *introduced the issue*

Joseph: Basically what we are talking about is how we manage this transitional state from one query language to another.

Joseph: Any comments on that

Daniel F: Were there any alternatives other than introducing a new top level parameter

Joseph: Not currently

Tobias: I'm supportive of this approach

Kristina: What is the status with this issue are we ready for a PR around the broader query syntax change?

Joseph: I believe we are, its just a matter of the raiser of the issuer finding time to do a proposal, Daniel do you think you will have time?

Daniel F: Yes should be do-able

## Issue #214, update the text about the response returned by the browser API

Joseph: *introduced the issue*

Joseph: Marcos has suggested that we update the response examples to include a simple JS snippet instead of a JSON object, any objection

Tobias: I'm supportive of this.

## Issue 354

Joseph: *introduced the issue*

Oliver: I think these parameters (referenced in the issue) should become credential format specific.

Kristina: I think the data structure is already sufficient because the proof type

Joseph: The problem is the value here is a string, when COSE algorithm identifiers are negative integers

Kristina: I dont understand why the parameter needs to be credential format specific

Brian: I think its just adapting the definition to reflect when the credential format is JOSE based a string based identifier is used vs when a COSE based format is used a negative integer based identifier should be used.

Nemanja: I think in practise the parameter is already credential format specific its just the data type for the elements in the list at the moment is generic when it should be informed by the credential format.

Joseph: Do we have any consensus about whether for COSE based credentials we should be using integer or string

Tobias: I'm supportive of integers as that is what the registry is based on

Mike: I agree

Oliver: I just think we make the parameter fully format specific

Torsten: I agree with this

Joseph: Does anybody disagree with this approach?

*No objections*

Joseph: Do you want to do a PR for this issue Oliver?

Oliver: Yes I can do a PR

## PR's ready for review

Joseph: There are multiple PR's ready for review over OpenID4VP and OpenID4VCI, please review over the next couple of days.

# Issues (OpenID4VCI)

## Issue 355 Issuer Trust Evidence / key attestations for OpenID4VCI

Torsten: *introduced the issue*

Torsten: Paul has created an initial proposal for this which is in the issue comments, it defines a new proof type which I'm personally not convinced of at this point.

Torsten: I have left a comment with some further thoughts around how I think this problem can be solved.

Torsten: Any questions at this point? Its important to get an approach sorted because the EUDI wallet is reliant on it.

*lots of discussion, please review recording :)*

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/20240716/c0b888c7/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/20240716/c0b888c7/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/20240716/c0b888c7/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/20240716/c0b888c7/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/20240716/c0b888c7/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/20240716/c0b888c7/attachment-0009.png>