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

[Joseph Heenan]

(These were done using the Zoom AI companion and then manually fixed up a bit, so the format is quite different to the normal manually taken minutes)

Date: 11th January 2024
Attendees:
Michael Jones
Brian Campbell
Bjorn Hjelm
George Fletcher
Tom Jones
Nick Burgess
David Luna
Pedro Felix
Judith Kahrer
Fabian Hauck
Oliver Terbu
Torsten Lodderstedt
Daniel Fett
Giuseppe De Marco
Christian Bormann
David Chadwick
Paul Bastian
Kristina Yasuda
Joseph Heenan
PR Restructuring Discussion and Event Description Debate
The team discussed a pull request (PR) concerning the restructuring of display objects from an array to a map. The consensus was that the new approach was not significantly better than the current one. Despite this, Guiseppe suggested continuing the discussion as several developers and analysts found the proposed approach interesting and worth exploring further. Daniel agreed to close the PR for now, suggesting that if new use cases arise, a new PR can be proposed. Kristina agreed to close the PR and open a new issue if needed. The team also briefly discussed a separate topic about using event descriptions instead of certifications, but no clear decision was made.
Signed Credential Issuer Metadata
Kristina raised a topic regarding the enforcement of the use of signed metadata and the potential impact on the wall that doesn't support it. There were still outstanding questions and concerns from Paul and Giuseppe. Paul expressed his issues with the assigned metadata not being bound to the credential issuer, proposing that the sub claim and the signed metadata job should match the credential issue. Torsten agreed with Paul, while Oliver suggested renaming the term "credential issuer origin identifier" to "credential issue identifier" for simplicity. They all agreed that the sub claim should be the original issuer and the Iss claim should be the actual credential issuer.
We discussed various aspects of the document they were working on. Paul proposed removing certain sentences and modifying others, including the 'iss' and 'sub' conditions, and the 'credential issue' term. There was a debate about the use of the word 'enforce' in relation to metadata, with David suggesting replacing 'should' with 'must'. The team agreed to mandate 'iss' and 'sub' in the signed JWT and to match the credential identifier. There was also a discussion about the requirement for a wallet to establish trust in designer and obtain the keys to validate the signature before processing the metadata. Kristina asked for clarification on certain points from Giuseppe, who suggested capitalizing 'credential issue' where appropriate.
The team discussed the scalability of a system involving signed metadata, particularly in large ecosystems with multiple trust frameworks. The current design's restrictive single signer requirement was criticized, but adding multiple versions was deemed complex. Joseph, Kristina, and others suggested alternative approaches, including allowing multiple trust anchors and the possibility of self-signing metadata. The team agreed to make these suggestions explicit in the text and to continue discussing metadata signers. There was also a discussion about integrating a particular feature into the implementer's draft, with concerns raised about scalability. Paul clarified that the feature was not a breaking change, and the urgency was somewhat lessened. The team agreed that supporting multiple trust anchors was a broader issue needing resolution and planned to continue the conversation regarding metadata signers.
Normative Change, Formatting, and Issue Metadata Signers
The team discussed a potential normative change and decided to merge it without worrying about the formatting. They also addressed concerns about the value appearing as a claim in the giant and decided it should not be a must. The team agreed to open an issue to better define the requirement of multiple issue metadata signers. They also received approval for the suggested changes, which Kristina dismissed to unblock the process.
Spec Review, Editorial Issues, and Normative Change
The team, including Kristina, Michael, Torsten, Brian, Joseph, and Paul, discussed the review process of a spec and handling editorial issues. They agreed to have a week between the working group last call and the foundation-wide review. The team decided to aggressively apply any feedback received. There was also a discussion about a potential normative change. Paul and Oliver discussed the issue of the format parameter in the credential request and response. Paul suggested deleting the format claim in the credential response to avoid confusion, which Oliver agreed with under certain conditions.
Change Implementation and Transparency Discussion
The team discussed the implementation of a change, with Joseph expressing uncertainty about the timeline. Michael clarified that the change could be merged a week from now and that being upfront with the working group was important. There was also a discussion about a normative change and the need for transparency. Kristina suggested making the change optional and removing some format from the examples. The team agreed to merge the editorial changes and to start the foundation wide review. Paul proposed making a pull request for people to decide for themselves, and Michael emphasized the need for clear communication. There was also a discussion about deleting some lines, with Brian suggesting editorial changes. The team agreed to address the deletion issue in a new issue and to merge the current pull request once the suggested changes were implemented.
Next steps
• Closing the PR for the use of map for display objects 
• Addressing the concerns and questions about the use of event description
• Daniel will open an issue on adding a section defining processing rules for the signed metadata data
• Paul to create a PR for discussing the removal of format in the credential response.
• Kristina to merge the editorial changes PRs in the next day or two.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240125/a0ee3aed/attachment-0001.html>