[Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call (PST midday)

Thu Oct 17 17:10:15 UTC 2024

Hi All,

Below are the meetings notes for the DCP WG call on the 17th of October 2024 – Query Language galore:

Best Regards,

Christian

----

Participants:

Christian Bormann

Joseph Heenan

Kristina Yasuda

Torsten Lodderstedt

Andreea Prian

Bjorn Hjelm

Brian Campbell

Daniel Fett

David Chadwick

Hicham Lozi

Hughes Andrew

Jan Vereecken

Javier Ruiz

Juba Saadi

Lukasz Jaromin

Martijn Haring

Michael Jones

Nemanja Patrnogic

Paul Bastian

Pedro Felix

Rajvardhan Deshmukh

Steve Venema

Tom Jones

----

Upcoming events: In-person meeting before IIW confirmed shifted to Microsoft and you need to be registered. If you registered before the switch, you do not need to register again.

General plan: Bring OpenID4VP and OpenID4VCI to ID before the end of the year, which means we need to merge PRs next Tuesday.

----

https://github.com/openid/OpenID4VP/pull/266 - Introduce new query language (Approach 3):

and https://github.com/openid/OpenID4VP/pull/281 - and Proposed alterations to how optionality is handled in query language (Approach 3)

Kristina explains the current state of the PR and that there is a PR from Tobias towards the current PR that changes how the claim sets are used. In the new proposal, you would have 2 different objects to express optionality of request claims. Another question is that right now credential_sets is an array of arrays and there was a discussion of turning it into an array of objects.

Paul asks about the ids within claims still exists in the example of Tobias. Daniel Fett and Martijn say that you need the ids for the claim_sets, but Torsten disagrees. Martijn asks how you would ask for attribute a or b from a credential and Torsten answers that this is solved on the upper level. Torsten continues that if we keep the claim_sets, then these changes are not simpler than the original syntax. Martijn worries that if you move that towards the credential level, then this might become messy. The fundamental question that Martijn asks is how the optionality would work on credential or claim level instead of use-case level. 

Paul mentions that in very complex examples, the proposal from Tobias might become very big and hard to handle, but does believe that those are going to occur very often, making the proposal from tobias easier to manage for "normal" use-cases. Daniel mentions that if we keep claim_sets, we can keep the "?" annotation, but wonders if Tobias wanted to keep claim_sets or not. Optionality at the credential level was changed from OR of ANDs to AND of ORs of ANDs which makes it a more difficult to manage. Daniel continues that if you add purpose, then this additional complexity might make sense because it matches very well to express purpose to the user. 

Torsten asks Martijn what kind of use-case could not be expressed without the claim_sets in the new proposal and states that he would prefer the proposal of Tobias without the claim_sets. Martijn agrees that you don't exactly need the claim_sets and thinks it was by choice to keep them, but it might be easier to remove them initially. Martijn explains that for him the "?" and the different "credentials" are different and make it clearer to the user that they are equivalent on a use-case level. Daniel responds that it does not change anything in terms of what you can express, just syntactical feature that does not really make a difference. Martijn responds, that it would not make sense to use that kind of optionality with the proposal from Tobias – RPs would not use it. Kristina clarifies that it would still be possible to do and to asks to not hang up on the optionality discussion too much. David says that you should be looking at the problem from the user perspective and from that perspective if you ask for an optional request, you would need to add a purpose.

Kristina asks for opinions on the 2 open questions and Christian answers that he likes removing the claim_sets for the time being. Martijn states that he would rather keep claim_sets but given that we could re-introduce it later on, he would be fine with removing it initially. Paul would like to keep claim_sets because it would make the structure of credentials and the query similar. Torsten states that he is in favor of adopting the proposal of Tobias without the claim_sets and he believes that we can re-enable them if we figure out it helps and in theory we could still add a flag for optionality if we really need to with the proposal from Tobias. Torsten continues that this seems to be the simplest option going forward and is a good start for the ID. Martijn agrees, that we could add an additional parameter for conditionality.

--> Rough consensus is to remove claim_set for now from the proposal of Tobias and we will use an array of objects.

Kristina asks about the "purpose" parameter and explains that there were concerns with a string of free text. Torsten replies that we will have that challenge anyway coming up and states that we likely need something like that. Kristina asks if Martijn would be fine with starting by including purpose as a string and Martijn responds that from a security perspective, providing free text will be abused and is in favor of adding ints/enums. Kristina asks if we can start with purpose being both (string and enum) for this version. Torsten mentions that he understands the concerns of Martijn but thinks it will be really hard to pre-register all purposes and is convinced we need the support of free text, especially initially. Martijn explains that he understands the need, but fears it will be abused and we should not ignore the problem. David mentions that the wallet will be able to find out if the Relying Party is trust-worthy (via client_id scheme) and if it is trustworthy, the wallet should display the string to the user because it trusts the RP.

--> Kristina summarizes that the authenticated RP string might be a starting point - free text and enum (integer) are allowed, but free text is only rendered for a trusted RP. Martijn asks for explicit notion that purpose might change later on.

Torsten asks about value matching and states that he thinks it is important. He explains that he would expect an incremental process where you request several credentials like a diploma first and then for the second credential you request a PID or mDL from the wallet with a matched value of the holder. Martijn explains that there might be slightly different names from document to document, but all components like browser, wallet, etc. need to implement this feature. Torsten asks why the Browser would need to have access to the credential and at least for the design of the credential matcher he has seen, this should not be a problem. Martijn explains that you might not have knowledge in the credential selector which would mean you cannot implement openid4vp. Paul states, that this should be an optional feature. Hicham mentions that he believes that supporting this feature would require drastic changes to the privacy and security assumptions of the solution. David explains that he thinks there are 2 types of value matching, 1 where the RP asks for a credential matching a specific value and the 2nd one would be matching values between 2 different credentials and asks why you need this if you have a cryptographic binding between the 2. Christian mentions that he thinks this should be seen as a hint instead of a hard requirement. Torsten answers that this might result in wrong credentials being provided, which is also a privacy and UX risk.

--> Kristina asks to continue discussion on the PR and try to reach an agreement, so we can merge before Tuesday.

TLDR:

- remove claim_sets  (but figure out if we want it back for 1.0 in the long run)

- introduce equivalent of ?! in credentials objects

- change credential_sets to array of objects

- add purpose to the object in credential_sets array - it can be a string or an integer, but it has to be shown only if the RP is authenticated

----

Kristina quickly explains the state of the other PRs in OpenID4VP on track to be included for ID:

- https://github.com/openid/OpenID4VP/pull/282 is ready to get merged and as a result

  - https://github.com/openid/OpenID4VP/pull/280 will get closed

  - https://github.com/openid/OpenID4VP/pull/279 will get closed

- https://github.com/openid/OpenID4VP/pull/274 gets unblocked by this and should get merged soon

- https://github.com/openid/OpenID4VP/pull/258 is superseded by the query language PR

- https://github.com/openid/OpenID4VP/pull/254 needs reviews

- https://github.com/openid/OpenID4VP/pull/197 needs reviews

From: Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols-bounces at lists.openid.net> On Behalf Of Kristina Yasuda via Openid-specs-digital-credentials-protocols
Sent: Tuesday, October 15, 2024 5:55 PM
To: Digital Credentials Protocols List <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Kristina Yasuda <yasudakristina at gmail.com>
Subject: [Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call (PST midday)

Hi All,

Below is the suggested agenda for today's DCP WG + SIOP call: https://zoom.us/j/94085567252?pwd=cHNFMExFalhlM2MrOFhoN3J6eDRuZz09

1. OIDF Antitrust Policy at www.openid.net/antitrust <http://www.openid.net/antitrust>  applies

2. IPR reminder/ Note-taking

3. Introductions/re-introductions

4. Agenda bashing/adoption

5. Events/External orgs

   - location of the pre-IIW DCP WG changed from Cisco to MSFT, please register :)

6. Plans for taking specs to final

7. Next version priority PRs - many need reviews please:

    1. VP: new query language (option 3) https://github.com/openid/OpenID4VP/pull/266/

    2. VCI: Key attestations https://github.com/openid/OpenID4VCI/pull/389
    3. VP: transaction data https://github.com/openid/OpenID4VP/pull/197
    4. VCI: add option to use credential_configuration_id in credential request:  https://github.com/openid/OpenID4VCI/pull/392
    5. VP: discontinue ad hoc and inappropriate use of "OAuth URI"s  https://github.com/openid/OpenID4VP/pull/279 and https://github.com/openid/OpenID4VP/pull/280
    6. VP & VCI: Additional IANA considerations: Complete IANA Considerations section

Thank you!

Kristina

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