[Openid-specs-digital-credentials-protocols] 2024-01-04 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: 4th January 2024
Attendees:
Joseph Heenan
Kristina Yasuda
Mark Haine
Philipp Lehwalder
Daniel Fett
Pedro Felix
Paul Bastian
Oliver Terbu
Juba
Javier Ruiz
Giuseppe De Marco
Paul Bastian
Fabian Hauck
Sudesha Shetty
Michael Jones
Brian Campbell
George Fletcher
 
Doodle Poll, AI Notes, New Participants, IPR Policy, Membership Discussion.
Paul proposed discussing the results from a doodle poll, but Kristina suggested doing it on the mailing list due to the absence of many peopleon the call. There was also a discussion about the AI companion's notes, with Kristina confirming they would be shared on the mailing list. Two new participants, Philipp and Juba from Lissi, introduced themselves and were asked to sign the IPR policy of the OpenID Foundation. Kristina also encouraged everyone to consider either individual or organizational membership so you can vote rights on specs.
Github
Mark informed the team about the issue with Github notifications not replicating the email notifications from Bitbucket. He proposed a solution that would increase the mailing list messages, ensuring that people don't miss out on important repository updates. The team expressed their support for this change. 
Encryption_Required
Paul raised a concern about the naming of a certain component, suggesting the term "encryption_required" might be more precise. Brian agreed that including the term was probably useful, even though it was a bit terse. There was a discussion about whether to call it "required" or "encryption_required," with the consensus leaning towards "encryption_required" to avoid confusion. The team agreed that this naming was explicit and agreed to move forward with it once Brian gave his approval.
Logo Structure and Review Process Discussion
Kristina led a discussion about changes to the credential logo structure. She noted a concern raised by Joseph about the optional status of the URI and decided to make it required when the logo structure is present. Sudesha questioned the optional status of the URL in logo in the credential supported data, and Kristina agreed to make it required everywhere. Kristina also suggested getting more reviewers on board and asked Oliver, who was on vacation, if he could review. Towards the end of the meeting, Paul brought up a debate about mandating certain picture formats, which Kristina confirmed would be deferred for further discussion. The team agreed to place reviews as PR and merge once there are no objections.
Notification Endpoint Parameter Renaming Proposal
Kristina proposed renaming the 'error.description' parameter to 'event.description' in the notification endpoint. The team agreed that the term 'error' was misleading, as it was not actually an error, but an event. Paul suggested that the term 'credential_deleted' was confusing and should be changed. They considered using 'credential_accepted' as an example, but Kristina highlighted that different implementations of the same use case exist. The team also discussed potential changes to the text in the parameter and agreed to separate the discussion on this matter.
Data Structure Proposal and Language Identification Discussion
Kristina proposed changes to the display instrument data structure, suggested by a team member who likes computers, from an area of object to a map with a key as a language identifier. This change was supported by some team members, including Joseph, but Joseph expressed discomfort with the possibility that the statement could send a signal to developers about always using this line of code. Joseph pointed out potential issues with language identification and Kristina agreed to clarify that the structure doesn't always mean it can be looked up and sometimes one might have to iterate. The proposal was part of a larger discussion and PR, with Paul noting that the issue and PR were opened by the lissi team.
There was a discussion about a proposed change to a map structure, with concerns raised about potential complications and restrictions. Kristina pointed out that while the change might simplify certain lookup processes, it could also introduce challenges, such as case sensitivity and potential duplicate entries. Brian and Michael expressed a preference for maintaining the current structure. Daniel highlighted a small advantage of the old structure, where duplicate entries are more obvious. Near the end of the meeting, Sudesha suggested using fallback values as a potential solution.
The team discussed the issue of falling back to a default value in case a specific location could not be found. Sudesha suggested using a default English value as a fallback. The team also discussed the idea of making all identifiers lowercase to avoid errors and the need for complex localization. Kristina proposed leaving the issue open for feedback from the original proposers and suggested limiting the cases that could be used. The team agreed to this approach and asked Sudesha and Giuseppe to make comments based on the discussion.
Potential Changes and Privacy Considerations
The team discussed the potential changes and their challenges, with Kristina suggesting that if a slight benefit was identified, the time to make the change would be then. The team also deliberated on privacy considerations, with Michael proposing a text as a starting point for discussions. However, there were differing opinions on whether to include this text in the implementer's draft or to leave it open for further improvements. The team agreed to continue the discussion and potentially incorporate suggestions to enhance the text. They also discussed the process of mapping the Yidas articles to the relevant sections and agreed on the best approach for progress. The team emphasized the need to merge Oc normative PRs for a foundation-wide review of the draft. Kristina encouraged further ideas to improve the draft and reminded the team about the upcoming normative PR to be discussed.
Metadata Credentials Assignment and Security Risks
The team discussed the issue of assigning credentials to data parameters via signed metadata, raised by Kristina, and the potential security risks associated with this, as highlighted by Paul. Questions were raised about the necessity of metadata parameters being present in the plane and the binding between the host and the actual issuer. Kristina mentioned making changes based on feedback and encouraged further review and comments on the PR. Michael also recommended others to review the entire spec and make PRs for necessary editorial changes.
Next steps
• Kristina will summarize the results of the doodle poll on the mailing list.
• Kristina will merge the PRs once they receive approval.
• Giuseppe will add Italy’s mapping of relevant GDPR articles as a comment to the privacy PR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240125/4fbaea89/attachment-0001.html>