[Openid-specs-digital-credentials-protocols] [minutes] 29th May 2024 DCP WG call (hybrid call @ Identiverse)

Thu May 30 08:09:08 UTC 2024

Hi all,

Blow are the notes from DCP Hybrid call 29th of May  (Hybrid event @
Identiverse - 3h call).

--------

Participants:

Joseph Heenan
Kristina Yasuda
Andy Regenscheid
Brian Campbell
Christian Bormann
David Chadwick
Jan Vereecken
Joao Rodolfo Vieira Silva
John Bradley
Juba Saadi
Lukasz Jaromin
Mike Jones
Oliver Terbu
Pedro Felix
Ranjiva Prasad
Sebastien Bahloul
Tom Jones
Victor Lu

Agenda:

IPR reminder/ Note-taking
Introductions/re-introductions
Agenda bashing/adoption
Events/External orgs
Updates from Identiverse, if any
OpenID4VP and VCI topics below:

Introductions:

Ranjiva Prasad - Visa
Joao Rodolfo Vierira Silva - Itau Unibanco S.A.

--------

Topics:

OID4VP profile for the W3C Digital Credentials API -
https://github.com/openid/OpenID4VP/pull/155:

Kristina mentions that this was a lot of editorial changes and clean up.
Kristina asks Brian about the encrypted response mode with JARM and a
comment he left. Brian says that this should be treated as a new response
mode and defined or more description on how existing response modes map into
this. Joseph comments that direct post makes sense in his opinion and Brian
comments that in his view it doesn't make a lot of sense. There is some
discussion about trust in the browser and encryption. Kristina says that
there are 2 questions: if the response is encrypted, should it be JARM or
not and this working group should not be the one to mandate an encrypted
response. Brian says that JARM-like encryption should be used, but that he
is not sure it should be JARM directly. Joseph adds that one option would be
to ignore response_mode when using browser API and if an encryption key is
passed, then the response should be encrypted. Kristina asks about the
difference of ignoring response_mode and introducing a new response_mode
like "api" or "api.jwt" and there seems to be some consensus that that the
new response_mode would be the cleaner option. Joseph says instead of
referring to JARM, it should reference to section 6.3. Kristina will update
the PR with an explicit response_mode. Brian mentions that perhaps it should
be name a little more specific than "api" or "api.jwt". The new proposal is
"w3c_dc_api" and "w3c_dc_api.jwt".
Kristina asks about the expected_origins comments and why it should allow
for more than one origin. Brian explains that he was told there were cases
where it was not entirely sure where this would be used (one of several
backends). Kristina asks if anyone has a problem with allowing more than one
origin and no concerns are raised.

---

Query language discussions is postponed as neither Tobias nor Daniel are on
the call. Kristina asks people to look at the proposal in
https://github.com/openid/OpenID4VP/issues/178 and comment.

---

Transaction data -
https://github.com/openid/OpenID4VP/issues?q=is%3Aissue+is%3Aopen+label%3A%2
2transaction+data%22:

#172: Kristina explains that there seems to be consensus on this.

#173: Kristina explains that there are open questions for this one.
Currently it is an array of objects, but feedback from relying parties was
that passing it as an array of strings would be better (option 2 in the
issue). Question should be if it should be a hash or not. Lukasz says that
he thinks hashing the object seems to be the more elegant option. Brian says
that hashing raw JSON is problematic and that it needs to be base64 encoded.
Christian asks about the use-case of signing documents and Lukasz adds that
this seems to be an interesting use-case and needs a bit more thought.
Kristina adds that the hash of the document would also need to be added to
the transaction data. It would then be a requirement for the wallet to fetch
the document and control the hash. John adds that there might be concerns of
PII leakage if we return base64 encoded payload and a hash seems to be the
safer variant. Kristina confirms that this would mean we should always go
for option 2b - a signed hash.
Christian asks about the scope of this, whether it is intended to use this
only for payment and remote signature and Kristina clarifies that these are
the main use-cases right now, but the functionality is supposed to work with
all kinds of transaction data.

#174: There are 2 main options where to include transaction_data: make it
credential format specific and re-use existing objects or define a new
object that would be sent alongside the credential format specific
presentation. Kristina mentions that option 2 would require a lot of
additional work as well. Lukasz says that he thinks option 1 would be more
elegant. Jan adds that it is not really the task of the credential to convey
this information and having a separate object that links to one or more
credentials seems to be a better option. Brian adds that while it is a bit
of a weird overloading, it is not the credential itself but a presentation.
Jan says that if option 1 is including all of the transaction_data in the
kb-jwt, then option 2 feels more natural because the new token would link to
the credential. Christian adds that there might be problems creating a
generic object that can be used by all kinds of credential formats. John
adds that one thing to think about would be what this means for zero
knowledge proofs and how such a binding would work for these kind of proofs.
John adds that from a practical point of view he would like to not create 2
different signatures if we can get away with 1. There seems to be some more
discussion and though needed for this issue.

Google doc with the examples:
https://docs.google.com/document/d/1E_UlB3fh9zbWiPrzFThEnt69hYN60CWk/edit#he
ading=h.x3ay045bto1x

---

Verifier/Relying Parties need to be able to verify authenticity and validity
of (European Digital Identity) Wallets -
https://github.com/openid/OpenID4VP/issues/141:

Kristina explains that a lot of people are voting against option 1 and
option 2 or 3 seem to be preferred. John says that he thinks this is a
horrible idea, but if you have to do it, then it should be part of the
verifiable credential. John adds that it will be really hard to reach the
same level of pseudonymization. John asks what the purpose of this is and
there is some discussion on the intended usage and benefits of this. David
says that there is a downside of putting something into the credential.
Kristina adds that maybe we don't have enough information. John adds that we
should be really careful with this because if we got this wrong, we might be
defeating the whole purpose of the 3 party model. John adds that we should
model this as returning a second verifiable credential. John adds that
information about a wallet might be PII about the user and you are providing
additional data points for potential corelation.

---

Potential improvements for the big picture of issuance flows -
https://github.com/openid/OpenID4VCI/issues/294:

Kristina explains that there was some implementation feedback that the
current way of having to check format and type is error prone and
credential_configuration_id might be considered in the Credential Request
even when scopes are used. Joseph asks to clarify that we are talking about
changing one of the existing options or adding another option. Kristina says
that this is open for discussion, but there was some discussion about
implementations are not using metadata. Joseph says that in his opinion this
should still work without metadata if the credential_configuration_id is
just communicated out of band. Jan agrees with this proposal. Kristina will
bring it up to the working group in 2 weeks (after EIC), but there seems to
be consensus forming for this issue.

---

Rework credential and batch credential endpoint -
https://github.com/openid/OpenID4VCI/pull/293:

Kristina explains that there is an issue with introducing "proofs" that can
be providing one or more proof of possessions. Christian adds that he agrees
with Paul that this is a path to deprecate the singular proof in the long
run. Joseph adds that we should figure out if we are allowing breaking
changes and if so he agrees to get rid of proof and allow proofs with "one
or more". Brian adds that for the time being we are trying to keep backwards
compatibility and one or more seems fine for him. Kristina asks about the
differentiation of credential configuration and credential dataset within
the PR. Kristina asks for people to re-read this PR with the new terminology
in mind and comment on the terminology overall and its use in this PR.

---

clarify optionality of scope and authorization_details for Authorization -
https://github.com/openid/OpenID4VCI/pull/318:

Kristina explains that form a RAR RFC perspective, scopes and
authorization_details can be used in the same authorization request.
Currently the PR introduces mutual exclusivity for either scope or RAR and
Kristina asks for feedback. Christian asks if anyone is using them together
in an implementation and Kristina agrees that she does not think people are
using them together right now. Joseph clarifies that there is a sentence
allowing them to be present at the same time. Kristina asks Joseph to
comment that on that PR.

---

chore: added more examples illustrating the use of Authorization Servers
(AS) and Resource Servers (RS) in this specification -
https://github.com/openid/OpenID4VCI/pull/322:

Kristina explains that she is not comfortable separating credential issuer
and authorization server and the terminology does not seem aligned.
Christian says that Credential Issuer is defined right now as only the RS in
the terminology and this might be part of the issue. Joseph adds that he
thinks the AS should be on the left side and the RS on the right side.
Kristina asks to make that comment on the PR.

---

Clarification on the Credential Endpoint -
https://github.com/openid/OpenID4VCI/issues/313:

Kristina explains that c_nonce can be return from authorization server or
the credential response, but the proof needs a nonce. Oliver explains that
for him it seemed a bit contradicting whether c_nonce is required or not and
points out that the text should be adjusted according to whether we want
c_nonce required or not. Sebastien asks how we could be in a situation where
we do not have a c_nonce and Joseph explains that it is optional in the
token endpoint. Kristina explains that for existing Authorization Servers in
production it might be impossible to include it in the token endpoint. Brian
agrees that he thinks this ambiguity is a problem. Brian adds that nonce was
chosen optional in DPOP and if we want to follow the same model then it
should be optional. Oliver asks about the replay protection in DPOP and
Brian briefly explains the options with JTI and there is some discussion on
it. Kristina proposes to adopt a very similar model to DPOP. Joseph thinks
that adding Access Token Hash into the proof would be a valid way forward.
John adds that this depends on the expiration time of the access token.
Brian adds that DPOP does not deal with this and the server can always force
a nonce if the access tokens are long-lived. Joseph says that adding the
c_nonce in the token endpoint discussion should not be part of this
discussion. Christian adds that this means for issuers that always want a
fresh nonce this would create 2 signatures from the wallet - one to get the
nonce and one with the correct proof. Kristina adds that currently the proof
jwt does not contain JTI, so right now cannot be used to detect replay right
now.