[Openid-specs-digital-credentials-protocols] [minutes] APAC-friendly DCP WG + SIOP call (PST midday) 24th of September 2024

[Joseph Heenan]

Date: 24th September 2024
 
Attendees:
 
Kristina Yasuda
Joseph Heenan
Daniel Fett
Christian Bormann
Martijn Haring
Lukasz Jaromin
Nemanja Patrnogic
Niels Klomp
Giuseppe De Marco
Tobias Looker
Oliver Terbu
Michael Jones
Brian Campbell
Edmund Jay
Hicham Lozi
Gail Hodges
Rajvardhan Deshmukh
Tom Jones
Bjorn Hjelm

Events 

TPAC:  Productive joint meeting between payment and web people

Some pushback against Digital Credential browser api around privacy expectations and how to explain selective disclosure as it happens in sd-jwt/mdoc currently to users.

Looking to start work on issuance in browser profile, people seem to think it’s simple but we need to talk about what it means for VCI. Need to decide how to coordinate the different working groups.

The general model of oid4vp on top of browser API seems well accepted now compared to last year’s TPAC.


Ekyc vote:

OIDF members, please vote on the ekyc specs going to final: https://openid.net/vote-final-identity-assurance-specifications/ 

Even ‘abstain’ votes really help with meeting quorum.



Client id scheme security

https://github.com/openid/OpenID4VP/pull/263
 
Brian echoed his recent comment on the PR: We shouldn’t special case things, it’s never a good idea - in particular dids & federation. It’s confusing as those things already have colons in them. All new things should be prefixed.

Daniel/Joseph/Kristina said “did" isn’t really a special case. Daniel wasn’t sure about special casing federation.

Brian thinks “did" is a special case

MikeJ said that federation has been using https urls for a while and changing its behaviour now when deployments have been using it for years in production would be bad. 

Martijn asked about the value of client_id in the browser context. Joseph explained that in the signed request it’s used for telling the wallet how to establish trust. In unsigned, it’s used in (e.g.) the sd-jwt key binding aud and needs to be checked by the verifier so that credentials can't be replayed etc.

Martijn asked about the value of client id in a signed request that includes a x509 certificate and thinks it could be unnecessary. Kristina asked Martijn to open a new ticket so we can discuss.

In the unsigned browser case the spec currently says the wallet should use the web origin (i.e. a https url) as the client id - that causes confusion given those urls would normally mean it’s a federation client id, so we need to add a prefix for the browser API case.

Tobias said he’d prefer that we drastically simplify client id schemes, removing did and redirect_uri and that all client ids in VP would then be https urls.

Agreement we need to clarify the unsigned browser request case as per comment Kristina added onto the PR during the meeting and there was otherwise a rough consensus that the approach in the PR is okay even though some people would prefer other solutions.



VCI  Non-breaking Extensibility PR:

Kristina introduced that the text around RAR is weird and deviates from the text in the RAR spec.

https://github.com/openid/OpenID4VCI/pull/382/files

Mike says this is necessary for extensibility of the RAR request, and is the last change we need to agree before this PR can be merged.

Joseph said we could define an extensibility point instead, e.g. a ‘extensions’ member that all future non-breaking changes are put inside of.

We’d like an opinion from Torsten as one of the RAR spec authors, Kristina asked him if he can look at it.

To discuss again on Thursday




Query language

Daniel introduced the latest changes to PR 266.

Oliver talked about his comment that sd_alg_values etc aren’t actually needed. Tobias agreed and said he’s seen interoperability issues from this. Martijn agreed.

Kristina asked if this is only an mdl problem. Daniel said it applies to sd-jwt too.

Daniel suggested we leave it out of this revision - we could add it later if we find a use case for it.

Martijn asks some question about optionality (the ‘?’ Suffix on claims) - he’ll add comments on the PR in the next few days.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240925/5f9f7c1d/attachment-0001.html>