<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">SIOP Special Topic Call Notes 22-Sep-22<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Petteri Stenius<o:p></o:p></p>
<p class="MsoNormal">David Chadwick<o:p></o:p></p>
<p class="MsoNormal">Joseph Heenan<o:p></o:p></p>
<p class="MsoNormal">Torsten Lodderstedt<o:p></o:p></p>
<p class="MsoNormal">Bjorn Hjelm<o:p></o:p></p>
<p class="MsoNormal">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">David Waite (DW)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Petteri reported on the Finnish ID system being developed<o:p></o:p></p>
<p class="MsoNormal"> They have chosen SIOP<o:p></o:p></p>
<p class="MsoNormal"> It uses a wallet<o:p></o:p></p>
<p class="MsoNormal"> The credentials will be JSON-LD<o:p></o:p></p>
<p class="MsoNormal"> There is selective disclosure for age verification<o:p></o:p></p>
<p class="MsoNormal"> They are building a wallet from scratch to hold the Finnish identity documents<o:p></o:p></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">
https://dvv.fi/en/-/development-of-the-digital-identity-card-already-far-along-feedback-from-test-users-guiding-completion-of-the-mobile-application</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Public Review Period for Proposed Final Unmet Authentication Requirements Specification<o:p></o:p></p>
<p class="MsoNormal"> Nat had privately asked if there are multiple implementations of the specification<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that this a mandatory to implement requirement for IdPs using yes.com<o:p></o:p></p>
<p class="MsoNormal"> He said that there are least four different implementations in the yes.com ecosystem<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Pull Requests<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/pull-requests/">
https://bitbucket.org/openid/connect/pull-requests/</a><o:p></o:p></p>
<p class="MsoNormal"> PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)<o:p></o:p></p>
<p class="MsoNormal"> Torsten, Oliver, and David Chadwick are working on a new proposal for credential metadata<o:p></o:p></p>
<p class="MsoNormal"> It has a credentials_supported structure<o:p></o:p></p>
<p class="MsoNormal"> It has a "standard" element - for instance "iso-mdoc"<o:p></o:p></p>
<p class="MsoNormal"> They do not want issuers to have to invent something on top of the existing credential formats<o:p></o:p></p>
<p class="MsoNormal"> David said that each standard has their own naming schemes<o:p></o:p></p>
<p class="MsoNormal"> But we can use common display names to present information to the user<o:p></o:p></p>
<p class="MsoNormal"> Kristina is not a fan of the structure having the "standard" and the "proof" separately<o:p></o:p></p>
<p class="MsoNormal"> Some of these things are standard-specific already so we don't have to separately declare the "standard"<o:p></o:p></p>
<p class="MsoNormal"> Torsten understands Kristina's feedback and is leaning in that direction<o:p></o:p></p>
<p class="MsoNormal"> Torsten simplified his displayed proposed example to eliminate "standard" and to include, for instance "format": "jwt_vc"<o:p></o:p></p>
<p class="MsoNormal"> Kristina questioned whether to include @context<o:p></o:p></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<o:p></o:p></p>
<p class="MsoNormal"> For instance, a "university_degree" credential may be understood by the parties without @context<o:p></o:p></p>
<p class="MsoNormal"> @context is ignored in JSON-serialized VCs<o:p></o:p></p>
<p class="MsoNormal"> Kristina requested that this be described in multiple PRs<o:p></o:p></p>
<p class="MsoNormal"> For instance, the base PR shouldn't introduce @context<o:p></o:p></p>
<p class="MsoNormal"> Torsten thinks that it may be premature to write PRs<o:p></o:p></p>
<p class="MsoNormal"> Mike opined that PRs should be written once there is consensus on how to resolve an issue and not before<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that the decision to drop the top-level parameter has implications<o:p></o:p></p>
<p class="MsoNormal"> This would also have to be propagated to the authorization_details and credential issuance parameters<o:p></o:p></p>
<p class="MsoNormal"> The primary parameter "format" would determine the rest<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that we already have a "format" parameter<o:p></o:p></p>
<p class="MsoNormal"> This is an extension point<o:p></o:p></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<o:p></o:p></p>
<p class="MsoNormal"> PR #294: clarifying that aud is not required in a signed request in SIOPv2, issue #1602<o:p></o:p></p>
<p class="MsoNormal"> DW asserted that this is ready to merge<o:p></o:p></p>
<p class="MsoNormal"> We discussed the choice of <a href="https://self-issued.me">
https://self-issued.me</a> to indicate static metadata<o:p></o:p></p>
<p class="MsoNormal"> DW suggested we change this to <a href="https://self-issued.me/v2">
https://self-issued.me/v2</a><o:p></o:p></p>
<p class="MsoNormal"> We agreed on the call to change it to
<a href="https://self-issued.me/v2">https://self-issued.me/v2</a> and then merge<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Testing for OpenID4VC specs<o:p></o:p></p>
<p class="MsoNormal"> Joseph told us about writing tests for the OpenID4VC specs<o:p></o:p></p>
<p class="MsoNormal"> He is working with David Chadwick on this<o:p></o:p></p>
<p class="MsoNormal"> Joseph wrote initial tests for the issuance spec<o:p></o:p></p>
<p class="MsoNormal"> They use the pre-authorized code route<o:p></o:p></p>
<p class="MsoNormal"> He is also writing initial tests for the presentation spec<o:p></o:p></p>
<p class="MsoNormal"> Gail Hodges is asking the certification team about testing for the OpenID4VC specs<o:p></o:p></p>
<p class="MsoNormal"> Joseph doesn't have enough information to do estimates yet<o:p></o:p></p>
<p class="MsoNormal"> David Chadwick gave some background on his request for tests<o:p></o:p></p>
<p class="MsoNormal"> He wants to test the features that are already stable<o:p></o:p></p>
<p class="MsoNormal"> Then add more tests as additional features mature<o:p></o:p></p>
<p class="MsoNormal"> As background, Mike described that it's the responsibility of the working group to define testing requirements<o:p></o:p></p>
<p class="MsoNormal"> and it's the responsibility of the certification team to implement the tests<o:p></o:p></p>
<p class="MsoNormal"> Joseph reported that Kristina, Torsten, and Joseph wrote a document describing the desired tests<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Issues<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open">
https://bitbucket.org/openid/connect/issues?status=new&status=open</a><o:p></o:p></p>
<p class="MsoNormal"> #1643: Define error codes for the Credential Issuance Endpoint<o:p></o:p></p>
<p class="MsoNormal"> We discussed when to use the HTTP status code 400<o:p></o:p></p>
<p class="MsoNormal"> RFC 6750, Section 3.1 (Error Codes) describes the use of 400, 401, 403, or 405 with OAuth error codes<o:p></o:p></p>
<p class="MsoNormal"> David agreed to update the issue based on Torsten's comments and the information from RFC 6750<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal"> The next call will be Monday, September 26, 2022 at 4pm Pacific Time<o:p></o:p></p>
</div>
</body>
</html>