[Openid-specs-ab] 2024-07-11 SIOP/DCP meeting notes

[David Waite]

# OpenID DCP Meeting Notes, Jul 11, 2024

## Attendees

- Kristina Yasuda (Chair)
- Bjorn Hjelm
- Brian Campbell
- David Waite
- Gail Hodges
- Gareth Oliver
- Hicham Lozi
- Javier Ruiz
- John Bradley
- Joseph Heenan
- Juba Saadi
- Lucy Yang
- Lukasz Jaromin
- Martjin Haring
- Matteo Marangoni
- Pamela Dingle
- Pedro Felix
- Rajvardhan Deshmukh
- Renata Toktar
- Ryan Galluzo
- Steve Venema

## California DMV Hackathon

Gail Hodges and Lucy Yang

Gail: 

> Pulling together two hackathons in the Fall
> 
> - October 1st open to the public
> - November 1st open to governments and partnering vendors
> 
> Create use cases and use tools available from the California DMV
> 
> Not a traditional hackathon as it is parties will create a proposal
> around a use case before the event, as well as some development work

David Waite: Is there an announcement to share?

Gail: This is a preview for this group, the public announcement should
be in a week

Kristina: Are there any asks for the DCP group?

Gail: No asks at this time. We did reach out to the German government
to see if there was any code which could be used to help provide
tooling. If individuals outside of vendor participation would like to
provide support to participants that would be appreciated

## Transaction Data and Payments

Kristina: August 8th presentation of scenarios by implementers

Draft PR already created

## Issues

### Change some examples to MDOC format [#22](https://github.com/openid/OpenID4VP/issues/22)

Will ping Oliver to see if he can provide examples

### Specification is missing examples for request objects [#78](https://github.com/openid/OpenID4VP/issues/78) 

Missing examples where requests are being passed as direct request
object or via a reference to one. Rajvardhan volunteered, Kristina
offered assistance if needed

### Add further details of how errors are returned from Browser API including a example error response [#204](https://github.com/openid/OpenID4VP/issues/204) 

Kristina:  

Question of what should be protocol-level errors vs exceptions thrown
at the API level

May wish to transfer to WICG Digital Credentials API

Do we want to translate these into web platform errors

David Waite: we have some alignment with privacy since the selector
happens up front, but we may have information we do not want to leak
by the user cancelling out from within the wallet

Martjin: error codes be conservative to not leak information

Pedro: observations in comments are relevant; discussion around how
errors are conveyed via Browser API

Need a way to convey error codes and responses via the Browser API,
does the promise fulfill if there is an OpenID 

Kristina: we need to define how error codes are returned in the
OpenID4VP response over Browser API. Current assumption is via the
OpenID4VP response. We need to clarify which ones are handled within
the response object vs API. Invalid request might fall into that
category and has a parallel discussion in W3C.

Joseph - invalid request may happen at the wallet vs selector, e.g.
evaluating whether the verifier is authorized to ask for the information

### Add more information on the binding to the origin in Browser API [#209](https://github.com/openid/OpenID4VP/issues/209') 

Martjin: origin is part of the protocol, in credential format specific
items

We need to define how the origin is included, e.g. Device binding,
request signing, response encryption

Martjin: we both have general requirements across credential formats,
but some formats have specific requirements as well

Kristina:

1. Do we need expected origins to be returned in the response? We have
   audience in other credential formats
2. What value does expected origins have in unsigned requests

Martjin: processing rules around the client_id and origin are what we
meant

Kristina: did you also want additional text around expected_origin and
its security properties

Martjin: there are a few places were we aren’t clear how origin is used

## Pull Requests

### Add wallet_unavailable error code to fix #191 [#200](https://github.com/openid/OpenID4VP/pull/200) 

Kristina: please review, we need more approvals

### Remove client_metadata_uri authorization parameter [#210](https://github.com/openid/OpenID4VP/pull/210)

Kristina: please review (assigning more reviewers) need 2-3 more 
approvals

### Make path_nested path relative in the presentation submission example [#184](https://github.com/openid/OpenID4VP/pull/184)

Merged on call

### Co-existence of multiple query languages [#211](https://github.com/openid/OpenID4VP/pull/211)

Kristina: related to #178, whether there is a migration path from PE
or a coexistence, and whether there is implementer requirements
guidance around implementing one or both

Joseph: we talked about differentiating the two queries via a new
parameter vs old parameter, so they could co-exist at least temporarily.

Pam: if there are going to be multiple types of queries, `vp_query` as
a parameter name might be too broad

Pedro: it may be possible to include a type, like a media type, for
newer implementations

DW: we should aim to have a replacement query format rather than as
an extension point, so we should have a migration strategy