<div dir="auto">It would be great if how Finnish LD-Proof is approaching selective disclosure can be documented. It will help this community. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2022年9月23日(金) 4:48 Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="m_-3110177811645109254WordSection1">
<p class="MsoNormal">SIOP Special Topic Call Notes 22-Sep-22<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal">Petteri Stenius<u></u><u></u></p>
<p class="MsoNormal">David Chadwick<u></u><u></u></p>
<p class="MsoNormal">Joseph Heenan<u></u><u></u></p>
<p class="MsoNormal">Torsten Lodderstedt<u></u><u></u></p>
<p class="MsoNormal">Bjorn Hjelm<u></u><u></u></p>
<p class="MsoNormal">Kristina Yasuda<u></u><u></u></p>
<p class="MsoNormal">David Waite (DW)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Petteri reported on the Finnish ID system being developed<u></u><u></u></p>
<p class="MsoNormal"> They have chosen SIOP<u></u><u></u></p>
<p class="MsoNormal"> It uses a wallet<u></u><u></u></p>
<p class="MsoNormal"> The credentials will be JSON-LD<u></u><u></u></p>
<p class="MsoNormal"> There is selective disclosure for age verification<u></u><u></u></p>
<p class="MsoNormal"> They are building a wallet from scratch to hold the Finnish identity documents<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://dvv.fi/en/-/development-of-the-digital-identity-card-already-far-along-feedback-from-test-users-guiding-completion-of-the-mobile-application" target="_blank" rel="noreferrer">
https://dvv.fi/en/-/development-of-the-digital-identity-card-already-far-along-feedback-from-test-users-guiding-completion-of-the-mobile-application</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Public Review Period for Proposed Final Unmet Authentication Requirements Specification<u></u><u></u></p>
<p class="MsoNormal"> Nat had privately asked if there are multiple implementations of the specification<u></u><u></u></p>
<p class="MsoNormal"> Torsten said that this a mandatory to implement requirement for IdPs using <a href="http://yes.com" target="_blank" rel="noreferrer">yes.com</a><u></u><u></u></p>
<p class="MsoNormal"> He said that there are least four different implementations in the <a href="http://yes.com" target="_blank" rel="noreferrer">yes.com</a> ecosystem<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Pull Requests<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/pull-requests/" target="_blank" rel="noreferrer">
https://bitbucket.org/openid/connect/pull-requests/</a><u></u><u></u></p>
<p class="MsoNormal"> PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)<u></u><u></u></p>
<p class="MsoNormal"> Torsten, Oliver, and David Chadwick are working on a new proposal for credential metadata<u></u><u></u></p>
<p class="MsoNormal"> It has a credentials_supported structure<u></u><u></u></p>
<p class="MsoNormal"> It has a "standard" element - for instance "iso-mdoc"<u></u><u></u></p>
<p class="MsoNormal"> They do not want issuers to have to invent something on top of the existing credential formats<u></u><u></u></p>
<p class="MsoNormal"> David said that each standard has their own naming schemes<u></u><u></u></p>
<p class="MsoNormal"> But we can use common display names to present information to the user<u></u><u></u></p>
<p class="MsoNormal"> Kristina is not a fan of the structure having the "standard" and the "proof" separately<u></u><u></u></p>
<p class="MsoNormal"> Some of these things are standard-specific already so we don't have to separately declare the "standard"<u></u><u></u></p>
<p class="MsoNormal"> Torsten understands Kristina's feedback and is leaning in that direction<u></u><u></u></p>
<p class="MsoNormal"> Torsten simplified his displayed proposed example to eliminate "standard" and to include, for instance "format": "jwt_vc"<u></u><u></u></p>
<p class="MsoNormal"> Kristina questioned whether to include @context<u></u><u></u></p>
<p class="MsoNormal"> She said that, as discussed in the VCWG last week, there are JSON credentials that don't use @context data structures<u></u><u></u></p>
<p class="MsoNormal"> For instance, a "university_degree" credential may be understood by the parties without @context<u></u><u></u></p>
<p class="MsoNormal"> @context is ignored in JSON-serialized VCs<u></u><u></u></p>
<p class="MsoNormal"> Kristina requested that this be described in multiple PRs<u></u><u></u></p>
<p class="MsoNormal"> For instance, the base PR shouldn't introduce @context<u></u><u></u></p>
<p class="MsoNormal"> Torsten thinks that it may be premature to write PRs<u></u><u></u></p>
<p class="MsoNormal"> Mike opined that PRs should be written once there is consensus on how to resolve an issue and not before<u></u><u></u></p>
<p class="MsoNormal"> Torsten said that the decision to drop the top-level parameter has implications<u></u><u></u></p>
<p class="MsoNormal"> This would also have to be propagated to the authorization_details and credential issuance parameters<u></u><u></u></p>
<p class="MsoNormal"> The primary parameter "format" would determine the rest<u></u><u></u></p>
<p class="MsoNormal"> Kristina said that we already have a "format" parameter<u></u><u></u></p>
<p class="MsoNormal"> This is an extension point<u></u><u></u></p>
<p class="MsoNormal"> David Chadwick said that the key issue is whether the different metadata formats can be unified or whether they should be format-specific<u></u><u></u></p>
<p class="MsoNormal"> PR #294: clarifying that aud is not required in a signed request in SIOPv2, issue #1602<u></u><u></u></p>
<p class="MsoNormal"> DW asserted that this is ready to merge<u></u><u></u></p>
<p class="MsoNormal"> We discussed the choice of <a href="https://self-issued.me" target="_blank" rel="noreferrer">
https://self-issued.me</a> to indicate static metadata<u></u><u></u></p>
<p class="MsoNormal"> DW suggested we change this to <a href="https://self-issued.me/v2" target="_blank" rel="noreferrer">
https://self-issued.me/v2</a><u></u><u></u></p>
<p class="MsoNormal"> We agreed on the call to change it to
<a href="https://self-issued.me/v2" target="_blank" rel="noreferrer">https://self-issued.me/v2</a> and then merge<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Testing for OpenID4VC specs<u></u><u></u></p>
<p class="MsoNormal"> Joseph told us about writing tests for the OpenID4VC specs<u></u><u></u></p>
<p class="MsoNormal"> He is working with David Chadwick on this<u></u><u></u></p>
<p class="MsoNormal"> Joseph wrote initial tests for the issuance spec<u></u><u></u></p>
<p class="MsoNormal"> They use the pre-authorized code route<u></u><u></u></p>
<p class="MsoNormal"> He is also writing initial tests for the presentation spec<u></u><u></u></p>
<p class="MsoNormal"> Gail Hodges is asking the certification team about testing for the OpenID4VC specs<u></u><u></u></p>
<p class="MsoNormal"> Joseph doesn't have enough information to do estimates yet<u></u><u></u></p>
<p class="MsoNormal"> David Chadwick gave some background on his request for tests<u></u><u></u></p>
<p class="MsoNormal"> He wants to test the features that are already stable<u></u><u></u></p>
<p class="MsoNormal"> Then add more tests as additional features mature<u></u><u></u></p>
<p class="MsoNormal"> As background, Mike described that it's the responsibility of the working group to define testing requirements<u></u><u></u></p>
<p class="MsoNormal"> and it's the responsibility of the certification team to implement the tests<u></u><u></u></p>
<p class="MsoNormal"> Joseph reported that Kristina, Torsten, and Joseph wrote a document describing the desired tests<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Issues<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open" target="_blank" rel="noreferrer">
https://bitbucket.org/openid/connect/issues?status=new&status=open</a><u></u><u></u></p>
<p class="MsoNormal"> #1643: Define error codes for the Credential Issuance Endpoint<u></u><u></u></p>
<p class="MsoNormal"> We discussed when to use the HTTP status code 400<u></u><u></u></p>
<p class="MsoNormal"> RFC 6750, Section 3.1 (Error Codes) describes the use of 400, 401, 403, or 405 with OAuth error codes<u></u><u></u></p>
<p class="MsoNormal"> David agreed to update the issue based on Torsten's comments and the information from RFC 6750<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Next Call<u></u><u></u></p>
<p class="MsoNormal"> The next call will be Monday, September 26, 2022 at 4pm Pacific Time<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>