[Openid-specs-digital-credentials-protocols] 2024-01-25 SIOP/DCP meeting notes

Sun Jan 28 08:48:32 UTC 2024

Date: 25th January 2024

Attendees (incomplete, this is only the people that were speaking in
zoom/active in chat - sorry about that):

Kristina Yasuda

Torsten Lodderstedt

Daniel Fett

Gabe Cohen

Jacob Ward

Paul Bastian

Oliver Terbu

Michael Jones

George Fletcher

Lukasz Jaromin

--- General

Kristina mentions IIW coming up in April(16th to 18th). At the last IIW,
there was a DCP working group on monday before, but this time it conflicts
with an open wallet foundation event in Seattle. The proposal would be to
have a roughly 3 hour working group meeting on Friday (the day after IIW).
Please reach out if there are conflicts with the friday idea for a working
group meeting. Mike adds that we then also need a place for the meeting and
Kristina answers she will start looking.

--- Issues and PRs (VCI):

https://github.com/openid/OpenID4VCI/pull/220 - rename
credential_configurations to credential_configuration_ids:

Kristina explains that feedback came in that credential_configurations
points to credential_configuration metadata and credential_configuration_id
points to the same metadata. credential_configuration_ids would be cleaner /
close than credential_configurations. Kristina mentions that there are five
approvals, so it seems like people agree that credential_configuration_ids
is a cleaner approach.

Christian asks why some of the examples have no reference in the spec and
after some discussions decisions is made to create a list for examples that
are not referenced in the spec and decide from there.

https://github.com/openid/OpenID4VCI/pull/219 - added format to
authorization details and respective format specific additional claims:

Kristina explains that we only have 2 approvals, would be nice to have a few
more. Kristina mentions the problem with conditional claims and the
formulation according to IETF. George adds that someone reading this without
the history of the spec makes it confusing. Torsten explains the problem
that the claims are mutually exclusive which ist not covered by IETF
wording. George says he would prefer the more complex REQUIRED formulation.
Lukasz adds that he would be confused with the longer REQUIRED formulation.

Kristina creates 3 options and asks for feedback and Lukasz expresses that
he prefers option 1.  Overall agreement with the last presented option to
directly express REQUIRED when <..>.

https://github.com/openid/OpenID4VCI/pull/232 - Fix layout in "VC Secured
using Data Integrity" issuer metadata:

Short discussion about what indentation is correct here and merged.

https://github.com/openid/OpenID4VCI/pull/187 - Wrote initial Privacy
Considerations:

Kristina asks for everyone to take a bit of time right now and read if
possible as it was changed very recently. Paul expresses that the section on
selective disclosure seems to be pretty specific and there are other
credential types like zkp based ones that give that choice completely to the
holder. Torsten adds that he would like to keep it simple in openid4vci and
mike agrees. Kristina proposes to create a more generic statement and Mike
agrees that he can do that. Jacob asks who this segment is intended for and
Mike explains mainly issuer and wallet - the parties implementing the spec.
Daniel and Gabe volunteered to review the PR. Kristina explains that in
general she would like to have cleaner segments.

https://github.com/openid/OpenID4VCI/issues/37 - Missing link between
cryptographic_suites_supported and format of credential:

Kristina explains that there are 2 issues, 37 and 217 on the
cryptographic_suites_supported parameter and it is currently unclear what it
applies to. Kristina explains that Timo is suggesting to rework the
definition of cryptographic_suites_supported to refer only to the
cryptosuites. Torsten asks if this means we have no metadata what kind of
signatures and algorithms are supported by the issuer? Kristina says that
there seem to be 3 options: Option 1 cryptosuites_supported is for both,
Option 2 where crypto suites only apply to the proof which, Option 3 where
the structure of proof_types is changed from array to map and clarify that
crypto_suites_supported.

Paul adds that issue #214 is a similar issue and he agrees to go with the
map route (option 3). Jacob asks if crypto suites in that map would then
only apply to proofs or the credential signature as well. Kristina answers
that within the map it would only apply to the proof type and we would
crypto_suites_supported and clarify that that one would apply to credential
signatures.

Torsten asks if we need meta data to signal how the credential will be
signed. Kristina adds that some wallets verify the credentials they receive
from the issuer. Torsten explains that for the time being he prefers to keep
the metadata about credential signature and if we figure out we don't need
it later on it can still be removed.

Paul asks about holder binding and how that is also related. Kristina
explains that she believes there is some kind of relationship between proof
type and cryptographic_binding_supported as well. Paul adds that he thinks
there needs to be a bit more thought about the issue and we have not yet
enough information. Torsten agrees and Kristina will draft a PR with the
changes for the map. Paul will create a separate issue for holder binding.

Best Regards,

Christian Bormann

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