[Openid-specs-digital-credentials-protocols] DCP WG + SIOP Call : 2024-03-26 Minutes

Tue Mar 26 20:06:40 UTC 2024

Agenda:

Conformance team hiring
https://openid.net/certification-program-recruiting-java-developer/
Conflicts of 9th & 11th April calls with TDI/OAuthSecWorkshop
Browser API consensus to create a PR:
https://github.com/openid/OpenID4VP/issues/125
Request uri extension now has many approval, final consensus to merge:
https://github.com/openid/OpenID4VP/pull/59
SD JWT VC PR: https://github.com/openid/OpenID4VP/pull/115
Please review VP mdoc/mdl section updates:
https://github.com/openid/OpenID4VP/pull/128
Anything else to do for VP ID3? Current proposed list:
https://github.com/openid/OpenID4VP/issues?q=label%3Aid3+
EU interop event profiles:
https://drive.google.com/drive/u/3/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR
Mechanism for wallet to detect cross device flows:
https://github.com/openid/OpenID4VP/issues/134

Attendance:

- Orie Steele
- Kristina Yasuda
- Joseph Heenan
- Jan Vereecken
- Bjon Hjelm
- Christian Bormann
- Daniel Fett
- David Chadwick
- David Waite
- George Fletcher
- John Bradley
- Lukasz Jaromin
- Oliver Terbu
- Ryan Galluzzo
- Sam Goto
- Sebastien Bahloul
- Tim Cappalli
- Tobias Looker
- Torsten Lodderstedt

Introductions:

Sam Goto: Work for Google Chrome, glad to be here.

External Organizations and Upcoming Events:

Discussion of canceling upcoming calls that conflict with OAuthSecWorkshop.

Decision to cancel both 9th and 11th calls in April.

Tim: Federated Identity WG charter approved at W3C, see request to join as
member organizations shortly.
... We will look at OIDC Profiles for the FedCM API.

Joseph: We're hiring a Java Developer for conformance tests.

https://openid.net/certification-program-recruiting-java-developer/

... Vote on first implementers draft for OIDC 4 VCI is open.

Topic: Browser API Proposal

https://github.com/openid/OpenID4VP/issues/125

Torsten: We've been looking at how OIDC4VP can be profiled for W3C Digital
Credentials API.
... There have been iterations in the Google Doc.
... This API will replace custom schemes, and help wallet discovery and
invocation and support cross device flows.
... The proposal also covers regulatory requirements.
... see
https://docs.google.com/document/d/1A10PZ_DviMJeyy2mDFt2QLcXUbT4O2dc_BizNXAD2PQ/edit

Summary of the default mode in the document.

Summary of Request URI with POST method.

There exist regulatory requirements for a wallet to trust an EU cert that
is not in the web PKI.
See the section on RP Authentication.

Wallet posts nonce to verifier, in order to ensure freshness of signed
presentation requirements.

Torsten: Please provide feedback on this proposal.
... Are we ready to start a PR based on this proposal to OIDC4VP?

John: I like the proposal, but how will this work with the German
repudiable presentation flow?
Torsten: Great question, the PID style presentation would not use the same
session, we would use an hmac.
... the difference would be only in the credential and credential
presentation.

John: Seems like the credential is HMAC'd to verifier, instead of issuer
signed... and this will work with the German credential system.
... We can't do terminal verification in the same way, we will need to the
request URI scheme.

Tobias: Regarding https://github.com/WICG/digital-identities/issues/92
... It seems like the wallet always needs to validate the web origin, plus
a possible additional layer based on certificates or wallet provider nonce.
... Will the user need to select the trust model?

Torsten: The wallet would always get an attested origin, ... the wallet
would get some data about the RP.
... The web origin has some meaning, but it does not fulfill all regulatory
requirements.

Tobias: If negotiation happens out of band, the user might select a
credential, but then the system might dead end... this could impact
capability negotiation.

Torsten: Everything necessary for selection should be in the first request.
... I would like to see the full protocol flow happen through the browser
API.
... current proposal uses OIDC4VP for components that we might not see
supported in the browser API.
... we need to get implementer feedback.

Tim: Can we add a new parameter called "expected origin" instead of
overloading client id.
... A single client id might support multiple origins.

Torsten: The web platform provides the client id to the wallet.

Tim: The web origin was never meant to be a client id.

Torsten: Client id would be matched to the origin, we might need to rework
that part.

Oliver: In request URI post message flow

Torsten: Today, we assume it's the same client id and the web origin.

...

Torsten: we can use all the parameters of OIDC4VP...

John: If we do allow direct post, we will still need a response to the
browser... regarding dead end credentials, that's going to be hard to
eliminate... The idea with the web api, is that you don't know which
wallets the user has... the same RP might have several trust marks for
different organizations... what can we put into credential selection, in
the request, so that all metadata is offline available.
possibly trust paths, trust marks, etc... This information will help filter
wallets that cannot satisfy requirements.

Joseph: Not hearing any objections to this proposal. Any objections to
starting a PR for this as an appendix in OIDC4VP?

Tobias: We discussed alternative models that don't require nonce... seems
there are many parts of the solution still in progress.

Joseph: We will need implementation experience.

Oliver: I reserve the right to comment on the query syntax.

Joseph: We have consensus on the path forward.

Topic: https://github.com/openid/OpenID4VP/pull/59

Joseph: Any objections?

Torsten: Impressive number of approvals.
... big improvement, I will merge after the meeting.

Topic: https://github.com/openid/OpenID4VP/pull/115

Jan: Some comments on language, such as "unsecured payload" which was added
to SD-JWT-VC.
... there were questions on how to actually do the matching based on the
Path... based on the unsecured payload.

Kristina: We have 2 options... issuer signed jwt and sd-jwt won't have
values.
... so PE needs to assume the wallet reconstructs the verified version(
with disclosures / processing applied).
... or do something like mDoc... I agree with oliver that the unsecured
payload is probably the best path.

Oliver: the path parameter in PEx is defined over the input document... so
it's ambiguous in the context of SD-JWT.

Jan: sounds like you support the new query format.

Kristina: There is a thread on client id scheme, which I thought we agreed
to resolve on another issue.
... and one on algorithm values and client metadata.

Tobias: we have explicit language on this

Kristina: the verifier cannot specify per credential algorithms.

Kristina: in client metadata, it cannot be put into input descriptor level
algorithms. (ES256, EdDSA, ECDH).

Torsten: the format and input descriptor only applies to SD-JWT, syntax,
it's not about algorithms.

Tobias: Seems like a mistake to do negotiation in 2 places.

Torsten: Then we should do it in Presentation Definition only.

Oliver: We can't do that, it would be a breaking change.

Tobias: It should be in client metadata.

Kristina: This disagreement is not new, but this PR is not the place to
resolve it.

Jan: Why was the object empty being mentioned in the HAIP.

Torsten: because Mike Jones and I were resolving it, and Mike said as much
as possible belonged in the client metadata.... format was the only thing
that went into the input descriptor.

Oliver: Why?

Kristina: Client metadata applies to all credentials, input descriptor is
per credential requirements.

Tobias: Why request per credential?... we don't do this kind of negotiation
in OIDC.

Torsten: Because code paths are format specification.

Tobias: If you support SD-JWT with an alg for a given credential, why
create a new layer?

Torsten: We can get rid of client metadata, except it would be a breaking
change.
... we should address in a future PR, separate issue.

Orie: can we make breaking changes?

Joseph: Yes, we just want to keep them in small PRs when possible.

Topic: https://github.com/openid/OpenID4VP/pull/128

Joseph: Some updates regarding mdl/doc.
... please review.

Kristina: There seems to be several issues for id3.

Tobias: Is there any conversation about query syntax on id3?

Joseph: We wanted to defer, so we can land the browser API related stuff
first.

Topic: EU Interop Profiles

Joseph: Please review:
https://drive.google.com/drive/u/0/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR
... send your feedback to the list.

This Thursday, we will discuss high level requirements and priorities.

-- 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240326/8512f77e/attachment.html>