<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 19-May-22<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">Torsten Lodderstedt<o:p></o:p></p>
<p class="MsoNormal">Giuseppe de Marco<o:p></o:p></p>
<p class="MsoNormal">Brian Clickenbeard<o:p></o:p></p>
<p class="MsoNormal">Jo Vercammen<o:p></o:p></p>
<p class="MsoNormal">Tony Nadalin<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kristina said that perhaps we should start calling this the OpenID for Verifiable Credentials special topic call<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SIOP Whitepaper<o:p></o:p></p>
<p class="MsoNormal"> We published the first editor's draft of the whitepaper<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://openid.net/2022/05/12/openid-for-verifiable-credentials-whitepaper/">
https://openid.net/2022/05/12/openid-for-verifiable-credentials-whitepaper/</a><o:p></o:p></p>
<p class="MsoNormal"> We plan to update the use cases description<o:p></o:p></p>
<p class="MsoNormal"> We plan to enhance the comparison to DIDcomm<o:p></o:p></p>
<p class="MsoNormal"> Good comments are coming in<o:p></o:p></p>
<p class="MsoNormal"> We will continue working in the Google Doc<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://docs.google.com/document/d/1H556GIM_xD1yKl7rw1seq4bu83movFCkU8fQ7T8b1dI/edit#heading=h.vwd38qa4vfe4">
https://docs.google.com/document/d/1H556GIM_xD1yKl7rw1seq4bu83movFCkU8fQ7T8b1dI/edit#heading=h.vwd38qa4vfe4</a><o:p></o:p></p>
<p class="MsoNormal"> Some changes in the published Word doc are not yet in the Google Doc<o:p></o:p></p>
<p class="MsoNormal"> Kristina plans to incorporate these changes into the Google doc next week<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Open 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 #176: Base OpenID for Verifiable Presentations on OAuth<o:p></o:p></p>
<p class="MsoNormal"> Torsten asked if it's beneficial to be able to do presentation without an ID Token<o:p></o:p></p>
<p class="MsoNormal"> Existing wallets have presentation as the primary use case<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that implementing the ID Token functionality is an additional implementation barrier<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that scope values can be used to request credentials<o:p></o:p></p>
<p class="MsoNormal"> These are structured scope values (much like FHIR did)<o:p></o:p></p>
<p class="MsoNormal"> Mike said that AAD doesn't support dynamic scope values<o:p></o:p></p>
<p class="MsoNormal"> Kristina said these values will be static for a given deployment<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that this isn't like the Berlin Group scopes, which are truly dynamic<o:p></o:p></p>
<p class="MsoNormal"> Mike said that he believes that AAD also doesn't support scope names with colons in them<o:p></o:p></p>
<p class="MsoNormal"> Kristina asked if people agree with the general direction of this PR<o:p></o:p></p>
<p class="MsoNormal"> Mike agreed with it<o:p></o:p></p>
<p class="MsoNormal"> Tony disagrees with overloading scope in this manner<o:p></o:p></p>
<p class="MsoNormal"> He said that we fought to keep scopes unstructured in RFC 6749<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that should get feedback from implementers<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that the "openid" scope introduces dependencies among scope values ("profile", "email", etc.)<o:p></o:p></p>
<p class="MsoNormal"> Whereas the scopes in this PR can be processed independently<o:p></o:p></p>
<p class="MsoNormal"> Brian said that Occam's Razor says to keep things simple<o:p></o:p></p>
<p class="MsoNormal"> He said that the challenge is to communicate the technical experts' context to implementers<o:p></o:p></p>
<p class="MsoNormal"> Brian said that people at top corporations don't understand how OAuth or OpenID Connect work<o:p></o:p></p>
<p class="MsoNormal"> Or what value they provide<o:p></o:p></p>
<p class="MsoNormal"> He's constantly explaining the difference between OAuth and OpenID<o:p></o:p></p>
<p class="MsoNormal"> And the developers can still be lost<o:p></o:p></p>
<p class="MsoNormal"> Mike said that OpenID Connect is plumbing - not a consumer brand<o:p></o:p></p>
<p class="MsoNormal"> and we define End-User as being the human participant<o:p></o:p></p>
<p class="MsoNormal"> PR #170: rename to openid for credential issuance<o:p></o:p></p>
<p class="MsoNormal"> People suggested the name "OpenID for Verifiable Credential Issuance"<o:p></o:p></p>
<p class="MsoNormal"> This aligns with the branding in the whitepaper<o:p></o:p></p>
<p class="MsoNormal"> Tony said that some people will misunderstand this<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that we'll need to keep evangelizing our definition of the term "Verifiable Credential"<o:p></o:p></p>
<p class="MsoNormal"> PR #157: Building Trust between Wallet and Issuer<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that this is mostly security considerations<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that he'd addressed Mike's comments about the use of "x5c"<o:p></o:p></p>
<p class="MsoNormal"> Mike agreed to re-review<o:p></o:p></p>
<p class="MsoNormal"> Nat asked Torsten to create a related issue<o:p></o:p></p>
<p class="MsoNormal"> He wants us to record discussions in issues<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that, practically, some people will comment in issues and some will comment in PRs<o:p></o:p></p>
<p class="MsoNormal"> So it can be hard to keep track of both<o:p></o:p></p>
<p class="MsoNormal"> Torsten and Kristina said that there's already an issue on trust models for wallets<o:p></o:p></p>
<p class="MsoNormal"> Related issues are #1457 and #1461<o:p></o:p></p>
<p class="MsoNormal"> Nat brought up the situation where the issuer goes out of business<o:p></o:p></p>
<p class="MsoNormal"> We want the person to still be able to use the verifiable credential<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that in high-security scenarios, the issuer should be responsible for the whole lifecycle<o:p></o:p></p>
<p class="MsoNormal"> Giuseppe asked about having signed_jwk as a claim<o:p></o:p></p>
<p class="MsoNormal"> This is closer to the trust model used by eIDAS2<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that we added "x5c" to support attestations<o:p></o:p></p>
<p class="MsoNormal"> Giuseppe asked how long he has to provide feedback<o:p></o:p></p>
<p class="MsoNormal"> We agreed that one week would be fine<o:p></o:p></p>
<p class="MsoNormal"> <o:p>
</o:p></p>
<p class="MsoNormal">Open 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"> #1499: Clarify how SIOP/Open4VP can be used to present credentials offline<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that the needed keys would need to be retrieved in advance<o:p></o:p></p>
<p class="MsoNormal"> Whereas a DID may need to be verified in real time<o:p></o:p></p>
<p class="MsoNormal"> did:key might work offline but not most DID methods<o:p></o:p></p>
<p class="MsoNormal"> Nat said that this might not be a totally offline case<o:p></o:p></p>
<p class="MsoNormal"> For instance, the wallet might be offline whereas the verifier is online<o:p></o:p></p>
<p class="MsoNormal"> Other permutations of offline and online are possible as well<o:p></o:p></p>
<p class="MsoNormal"> Torsten agreed with Nat that we need to be clear what "offline" means and what use cases we want to support<o:p></o:p></p>
<p class="MsoNormal"> Torsten gave the example of entering a football stadium<o:p></o:p></p>
<p class="MsoNormal"> Kristina gave the examples of being stopped in a tunnel with no Internet connectivity<o:p></o:p></p>
<p class="MsoNormal"> and having just arrived in an international airport with no SIM card or Wi-Fi connection<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that AAMVA wants a comprehensive package<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that key management and revocation also come into play<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 on Monday, May 23, 2022 at 4pm Pacific Time<o:p></o:p></p>
</div>
</body>
</html>