[Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22

Mike Jones Michael.Jones at microsoft.com
Thu Sep 22 19:47:48 UTC 2022


SIOP Special Topic Call Notes 22-Sep-22

Mike Jones
Petteri Stenius
David Chadwick
Joseph Heenan
Torsten Lodderstedt
Bjorn Hjelm
Kristina Yasuda
David Waite (DW)

Petteri reported on the Finnish ID system being developed
              They have chosen SIOP
              It uses a wallet
              The credentials will be JSON-LD
              There is selective disclosure for age verification
              They are building a wallet from scratch to hold the Finnish identity documents
              https://dvv.fi/en/-/development-of-the-digital-identity-card-already-far-along-feedback-from-test-users-guiding-completion-of-the-mobile-application

Public Review Period for Proposed Final Unmet Authentication Requirements Specification
              Nat had privately asked if there are multiple implementations of the specification
              Torsten said that this a mandatory to implement requirement for IdPs using yes.com
                           He said that there are least four different implementations in the yes.com ecosystem

Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)
                           Torsten, Oliver, and David Chadwick are working on a new proposal for credential metadata
                           It has a credentials_supported structure
                           It has a "standard" element - for instance "iso-mdoc"
                           They do not want issuers to have to invent something on top of the existing credential formats
                           David said that each standard has their own naming schemes
                                         But we can use common display names to present information to the user
                           Kristina is not a fan of the structure having the "standard" and the "proof" separately
                                         Some of these things are standard-specific already so we don't have to separately declare the "standard"
                                         Torsten understands Kristina's feedback and is leaning in that direction
                           Torsten simplified his displayed proposed example to eliminate "standard" and to include, for instance "format": "jwt_vc"
                           Kristina questioned whether to include @context
                                         She said that, as discussed in the VCWG last week, there are JSON credentials that don't use @context data structures
                                         For instance, a "university_degree" credential may be understood by the parties without @context
                                         @context is ignored in JSON-serialized VCs
                           Kristina requested that this be described in multiple PRs
                                         For instance, the base PR shouldn't introduce @context
                                         Torsten thinks that it may be premature to write PRs
                                         Mike opined that PRs should be written once there is consensus on how to resolve an issue and not before
                           Torsten said that the decision to drop the top-level parameter has implications
                                         This would also have to be propagated to the authorization_details and credential issuance parameters
                                                       The primary parameter "format" would determine the rest
                                                       Kristina said that we already have a "format" parameter
                                         This is an extension point
                           David Chadwick said that the key issue is whether the different metadata formats can be unified or whether they should be format-specific
              PR #294: clarifying that aud is not required in a signed request in SIOPv2, issue #1602
                           DW asserted that this is ready to merge
                           We discussed the choice of https://self-issued.me to indicate static metadata
                           DW suggested we change this to https://self-issued.me/v2
                           We agreed on the call to change it to https://self-issued.me/v2 and then merge

Testing for OpenID4VC specs
              Joseph told us about writing tests for the OpenID4VC specs
                           He is working with David Chadwick on this
                           Joseph wrote initial tests for the issuance spec
                                         They use the pre-authorized code route
                           He is also writing initial tests for the presentation spec
              Gail Hodges is asking the certification team about testing for the OpenID4VC specs
                           Joseph doesn't have enough information to do estimates yet
              David Chadwick gave some background on his request for tests
                           He wants to test the features that are already stable
                           Then add more tests as additional features mature
              As background, Mike described that it's the responsibility of the working group to define testing requirements
                           and it's the responsibility of the certification team to implement the tests
              Joseph reported that Kristina, Torsten, and Joseph wrote a document describing the desired tests

Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1643: Define error codes for the Credential Issuance Endpoint
                           We discussed when to use the HTTP status code 400
                           RFC 6750, Section 3.1 (Error Codes) describes the use of 400, 401, 403, or 405 with OAuth error codes
                           David agreed to update the issue based on Torsten's comments and the information from RFC 6750

Next Call
              The next call will be Monday, September 26, 2022 at 4pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220922/c3022827/attachment.html>


More information about the Openid-specs-ab mailing list