[Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
Nat Sakimura
nat at nat.consulting
Fri Sep 23 08:36:40 UTC 2022
It would be great if how Finnish LD-Proof is approaching selective
disclosure can be documented. It will help this community.
2022年9月23日(金) 4:48 Mike Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net>:
> 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220923/39f56827/attachment.html>
More information about the Openid-specs-ab
mailing list