<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Petteri,</div><div dir="ltr"><br></div><div dir="ltr">thanks for sharing!</div><div dir="ltr"><br></div><div dir="ltr">It seems from the example the holder binding uses did:web. Are the different credentials bound to the same DID?</div><div dir="ltr"><br></div><div dir="ltr">best regards,</div><div dir="ltr">Torsten.</div><div dir="ltr"><br><blockquote type="cite">Am 26.09.2022 um 18:07 schrieb Petteri Stenius via Openid-specs-ab <openid-specs-ab@lists.openid.net>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">



<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof ContentPasted0">
Hi,
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">The selective disclosure model of Finnish ID system is quite simple:</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">- There's a relatively small number of claims.</div>
<div class="ContentPasted0">- Each claim is issued in a separate credential. </div>
<div class="ContentPasted0">- A relying party can request specific claims by using scope or claims parameter.
</div>
<div class="ContentPasted0">- Resulting vp_token contains one or more credentials with the requested claims.</div>
<div class="ContentPasted0">- The wallet app can refresh credentials so that claims such as age_over_18 have valid information.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">Link to more detailed information <a href="https://wiki.dvv.fi/display/DHHJD/SIOPv2+POC+-+Guide+for+Relying+Parties" id="LPNoLPOWALinkPreview">
https://wiki.dvv.fi/display/DHHJD/SIOPv2+POC+-+Guide+for+Relying+Parties</a> </div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">Petteri</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> on behalf of Nat Sakimura via Openid-specs-ab <openid-specs-ab@lists.openid.net><br>
<b>Sent:</b> Friday, September 23, 2022 11:36<br>
<b>To:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>Cc:</b> Nat Sakimura <nat@nat.consulting><br>
<b>Subject:</b> Re: [Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22</font>
<div> </div>
</div>
<div>
<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="x_gmail_quote">
<div dir="ltr" class="x_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="x_gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div lang="EN-US" style="word-wrap:break-word">
<div class="x_m_-3110177811645109254WordSection1">
<p class="x_MsoNormal">SIOP Special Topic Call Notes 22-Sep-22<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Mike Jones<u></u><u></u></p>
<p class="x_MsoNormal">Petteri Stenius<u></u><u></u></p>
<p class="x_MsoNormal">David Chadwick<u></u><u></u></p>
<p class="x_MsoNormal">Joseph Heenan<u></u><u></u></p>
<p class="x_MsoNormal">Torsten Lodderstedt<u></u><u></u></p>
<p class="x_MsoNormal">Bjorn Hjelm<u></u><u></u></p>
<p class="x_MsoNormal">Kristina Yasuda<u></u><u></u></p>
<p class="x_MsoNormal">David Waite (DW)<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Petteri reported on the Finnish ID system being developed<u></u><u></u></p>
<p class="x_MsoNormal">              They have chosen SIOP<u></u><u></u></p>
<p class="x_MsoNormal">              It uses a wallet<u></u><u></u></p>
<p class="x_MsoNormal">              The credentials will be JSON-LD<u></u><u></u></p>
<p class="x_MsoNormal">              There is selective disclosure for age verification<u></u><u></u></p>
<p class="x_MsoNormal">              They are building a wallet from scratch to hold the Finnish identity documents<u></u><u></u></p>
<p class="x_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="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Public Review Period for Proposed Final Unmet Authentication Requirements Specification<u></u><u></u></p>
<p class="x_MsoNormal">              Nat had privately asked if there are multiple implementations of the specification<u></u><u></u></p>
<p class="x_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="x_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="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Pull Requests<u></u><u></u></p>
<p class="x_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="x_MsoNormal">              PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)<u></u><u></u></p>
<p class="x_MsoNormal">                           Torsten, Oliver, and David Chadwick are working on a new proposal for credential metadata<u></u><u></u></p>
<p class="x_MsoNormal">                           It has a credentials_supported structure<u></u><u></u></p>
<p class="x_MsoNormal">                           It has a "standard" element - for instance "iso-mdoc"<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                           David said that each standard has their own naming schemes<u></u><u></u></p>
<p class="x_MsoNormal">                                         But we can use common display names to present information to the user<u></u><u></u></p>
<p class="x_MsoNormal">                           Kristina is not a fan of the structure having the "standard" and the "proof" separately<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                                         Torsten understands Kristina's feedback and is leaning in that direction<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                           Kristina questioned whether to include @context<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                                         For instance, a "university_degree" credential may be understood by the parties without @context<u></u><u></u></p>
<p class="x_MsoNormal">                                         @context is ignored in JSON-serialized VCs<u></u><u></u></p>
<p class="x_MsoNormal">                           Kristina requested that this be described in multiple PRs<u></u><u></u></p>
<p class="x_MsoNormal">                                         For instance, the base PR shouldn't introduce @context<u></u><u></u></p>
<p class="x_MsoNormal">                                         Torsten thinks that it may be premature to write PRs<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                           Torsten said that the decision to drop the top-level parameter has implications<u></u><u></u></p>
<p class="x_MsoNormal">                                         This would also have to be propagated to the authorization_details and credential issuance parameters<u></u><u></u></p>
<p class="x_MsoNormal">                                                       The primary parameter "format" would determine the rest<u></u><u></u></p>
<p class="x_MsoNormal">                                                       Kristina said that we already have a "format" parameter<u></u><u></u></p>
<p class="x_MsoNormal">                                         This is an extension point<u></u><u></u></p>
<p class="x_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="x_MsoNormal">              PR #294: clarifying that aud is not required in a signed request in SIOPv2, issue #1602<u></u><u></u></p>
<p class="x_MsoNormal">                           DW asserted that this is ready to merge<u></u><u></u></p>
<p class="x_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="x_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="x_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="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Testing for OpenID4VC specs<u></u><u></u></p>
<p class="x_MsoNormal">              Joseph told us about writing tests for the OpenID4VC specs<u></u><u></u></p>
<p class="x_MsoNormal">                           He is working with David Chadwick on this<u></u><u></u></p>
<p class="x_MsoNormal">                           Joseph wrote initial tests for the issuance spec<u></u><u></u></p>
<p class="x_MsoNormal">                                         They use the pre-authorized code route<u></u><u></u></p>
<p class="x_MsoNormal">                           He is also writing initial tests for the presentation spec<u></u><u></u></p>
<p class="x_MsoNormal">              Gail Hodges is asking the certification team about testing for the OpenID4VC specs<u></u><u></u></p>
<p class="x_MsoNormal">                           Joseph doesn't have enough information to do estimates yet<u></u><u></u></p>
<p class="x_MsoNormal">              David Chadwick gave some background on his request for tests<u></u><u></u></p>
<p class="x_MsoNormal">                           He wants to test the features that are already stable<u></u><u></u></p>
<p class="x_MsoNormal">                           Then add more tests as additional features mature<u></u><u></u></p>
<p class="x_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="x_MsoNormal">                           and it's the responsibility of the certification team to implement the tests<u></u><u></u></p>
<p class="x_MsoNormal">              Joseph reported that Kristina, Torsten, and Joseph wrote a document describing the desired tests<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Issues<u></u><u></u></p>
<p class="x_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="x_MsoNormal">              #1643: Define error codes for the Credential Issuance Endpoint<u></u><u></u></p>
<p class="x_MsoNormal">                           We discussed when to use the HTTP status code 400<u></u><u></u></p>
<p class="x_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="x_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="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Next Call<u></u><u></u></p>
<p class="x_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>
</div>


<span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span>Openid-specs-ab@lists.openid.net</span><br><span>https://lists.openid.net/mailman/listinfo/openid-specs-ab</span><br></div></blockquote></body></html>