1.   Roll Call

• Attending:
  • Nat Sakimura
  • David Waite
  • Brian Campbell
  • Edmund Jay
  • Vittorio
  • Naveen CM
  • Dima
• Regret:
• Guest:

2.   Adoption of Agenda (Nat)

• Adopted as is.

3.   External Orgs & Events

4.   PRs

• PR #468 - First draft of OpenID 4 VC Security Analysis
  • https://bitbucket.org/openid/connect/pull-requests/468
  • Lots of comments in PR. Discussion should be done in the issues instead of the PR.

5.   Issues

• #1849 - wrong client_id in section 6.2
  • old client_id using redirect_uri
  • Will fix
• #1848 - Typo in Section 5
  • The request_uri value should be changed to client_metada_uri
  • This issue seems to be fixed already in main text
  • Will verify
• #1847 - Add definition of jwt_vp_json in OID4VCI
  • Opened
• #1846 - Add more JSON.Path seucurity considerations in PE
  • There is concern about what can be used as a filter
  • Use of JSOn Paths can be potential security risks
  • There aren't a lot of considerations for it
  • David is working on restrictions on guidance
  • will need to know what people actually need
  • There are cases where presentation reqeust is insufficent especially for selective disclosure
  • A lot of work needs to be done in terms of denial of service attacks
  • There is insufficient guidance on how to make a non-naive implementation for things like complex path based filters
  • Work is ongoing
  • The section on naive implementationns need to reference on how people build things like CSS selectors
  • Is there any benefit in being so dynamic? Requires semantic knowledge of what people are asking for.
  • There will be a lot of security considerations and libraries may not have that in mind.
  • Narrow options and simplifying will be better, otherwise proving security properties will be * difficult/impossible
  • Non-optimized implementation of JSON libraries could be prone to denial of service attacks against user's wallets

6.   VP Spec

Spec quality needs some improvement

People have difficulties getting to the content

Editorial/conceptual problems makes it difficult to review and contribute

Some content seems to come straight from W3C/DIF definitions and then adopted

Some traditional Oauth/OIDC constructs like client_id used in different ways

e.g. Opaque identifier vs structured element for DID

There is a difficult learning curve for people not familiar with concepts

VP subgroup should engage with main group so others not working in that area can provide feedback

Spec is changing at fast pace makes it difficult for people to keep up.

Can defining using DIDs as a client_id in standalone spec for broader consumption be more useful rather than being defined in SIOP?

If SIOP has a new response mode, does it make sense to defined it outside of SIOP to make it more general?

So many concepts/components lumped into a single spec makes it more difficult for people to understand

European Digital Identity may be adopting it so need to figure out next steps to support it

7.   AOB

None

The meeting was adjourned at 23:41 UTC