<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;
margin-bottom:.0001pt;
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">
<div class="WordSection1">
<p class="MsoNormal">Spec Call Notes 22-Jun-20<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">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">Tim Cappalli<o:p></o:p></p>
<p class="MsoNormal">Tom Jones<o:p></o:p></p>
<p class="MsoNormal">Tobias Looker<o:p></o:p></p>
<p class="MsoNormal">Orie Steele (hasn't yet signed IPR agreement)<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Introductions<o:p></o:p></p>
<p class="MsoNormal"> Tobias and Orie are new to the call, so we did introductions<o:p></o:p></p>
<p class="MsoNormal"> Tobias Looker works for Mattr in New Zealand doing identity standards, including DIDs and VCs<o:p></o:p></p>
<p class="MsoNormal"> Orie Steele - CTO of Transmute in Austin, decentralized identifiers, DIDs, W3C CCG, uses OpenID Connect<o:p></o:p></p>
<p class="MsoNormal"> An author of <a href="https://identity.foundation/did-siop/">
https://identity.foundation/did-siop/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">OAuth JAR<o:p></o:p></p>
<p class="MsoNormal"> Mike reviewed Nat's PRs<o:p></o:p></p>
<p class="MsoNormal"> He asked to use the name "require_signed_request_object" that we'd agreed to on the Connect calls<o:p></o:p></p>
<p class="MsoNormal"> And to prohibit "alg":"none" when this is true<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Self-Issued OP Discussion<o:p></o:p></p>
<p class="MsoNormal"> Edmund's working claims aggregation draft<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.md">
https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.md</a><o:p></o:p></p>
<p class="MsoNormal"> Tobias' client bound assertions draft <o:p></o:p></p>
<p class="MsoNormal"> <a href="https://mattrglobal.github.io/oidc-client-bound-assertions-spec/">
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/</a><o:p></o:p></p>
<p class="MsoNormal"> Tobias wants to receive a bound assertion from an OpenID Connect flow<o:p></o:p></p>
<p class="MsoNormal"> Tom described a similar need in the healthcare space<o:p></o:p></p>
<p class="MsoNormal"> Tom wants to have a "bound token" that is bound to the issuer and the recipient<o:p></o:p></p>
<p class="MsoNormal"> Tobias said that a standard OpenID Connect audience can't authenticate<o:p></o:p></p>
<p class="MsoNormal"> Whereas a bound token is more like a DPoP token<o:p></o:p></p>
<p class="MsoNormal"> He believes that the best binding mechanism is public key crypto<o:p></o:p></p>
<p class="MsoNormal"> Nat asked what the use case is for re-presenting an ID Token is<o:p></o:p></p>
<p class="MsoNormal"> Tobias: How do we know that the SIOP provider is entitled to present the aggregated claims?<o:p></o:p></p>
<p class="MsoNormal"> Tobias: They don't want to have to use the "highly-available issuer" model, where the issuer is always online<o:p></o:p></p>
<p class="MsoNormal"> Tom: In our case, the identity proofing statement and the authentication capability statement come from different sources<o:p></o:p></p>
<p class="MsoNormal"> The third thing would be a proof of presence statement<o:p></o:p></p>
<p class="MsoNormal"> Tom made some of the claim values be JWSs<o:p></o:p></p>
<p class="MsoNormal"> Nat: Tony is working on Zero Knowledge Proof (ZKP) JWT assertions<o:p></o:p></p>
<p class="MsoNormal"> Tom: We need interoperable key rollover<o:p></o:p></p>
<p class="MsoNormal"> Tom's rough draft<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token">
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token</a><o:p></o:p></p>
<p class="MsoNormal"> Nat presented about SIOP at Identiverse last year<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://www.youtube.com/watch?v=GR29JQ-eB1k">
https://www.youtube.com/watch?v=GR29JQ-eB1k</a><o:p></o:p></p>
<p class="MsoNormal"> Tom wants claims to be verifiable in the sense that you can check the signature but they don't need to be online<o:p></o:p></p>
<p class="MsoNormal"> Tom: Sometimes the user and the subject are not the same entity<o:p></o:p></p>
<p class="MsoNormal"> For instance, parents making claims for children<o:p></o:p></p>
<p class="MsoNormal"> Nat said that this is an authorized party use case<o:p></o:p></p>
<p class="MsoNormal"> Tobias: How do you request claims from other claims providers in the authentication request?<o:p></o:p></p>
<p class="MsoNormal"> Nat: Right now there's not a way to specify the authoritative source for a set of claims<o:p></o:p></p>
<p class="MsoNormal"> Nat: This could be for SIOP or a normal OpenID Provider<o:p></o:p></p>
<p class="MsoNormal"> Tobias: You may want claims from particular sources and/or at particular assurance levels<o:p></o:p></p>
<p class="MsoNormal"> Tom: Sometimes Federations arrange assurance<o:p></o:p></p>
<p class="MsoNormal"> Nat: We intentionally punted these policies to the trust frameworks used<o:p></o:p></p>
<p class="MsoNormal"> Tom: You need a federation authority<o:p></o:p></p>
<p class="MsoNormal"> Nat: "acr" can be used to specify a trust framework<o:p></o:p></p>
<p class="MsoNormal"> Mike: How does this related to OpenID Connect for Identity Assurance<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0-10.html">
https://openid.net/specs/openid-connect-4-identity-assurance-1_0-10.html</a><o:p></o:p></p>
<p class="MsoNormal"> Tobias: All claims have some form of assurance associated with them<o:p></o:p></p>
<p class="MsoNormal"> Organizing them into two buckets is problematic<o:p></o:p></p>
<p class="MsoNormal"> Tom: Different communities are using different terminology in the verified claims space<o:p></o:p></p>
<p class="MsoNormal"> Tom: The entity statements from OpenID Federation can also be useful<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Self-Issued OP Meeting<o:p></o:p></p>
<p class="MsoNormal"> Mike asked how we're going to run a meeting of 50+ people on this very interesting topic<o:p></o:p></p>
<p class="MsoNormal"> Nat: We'll have to mute everyone<o:p></o:p></p>
<p class="MsoNormal"> Nat: Only the speakers will be unmuted<o:p></o:p></p>
<p class="MsoNormal"> Speakers will get 10-15 minutes<o:p></o:p></p>
<p class="MsoNormal"> Mike: How will we take questions?<o:p></o:p></p>
<p class="MsoNormal"> Nat: Use chat window to raise hand, then Nat will ask the questioner to speak<o:p></o:p></p>
<p class="MsoNormal"> It will be a lot like a panel discussion with ~6 speakers<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Tobias' Claims Request Document<o:p></o:p></p>
<p class="MsoNormal"> Mike asked about some details of Tobias' claims/credentials request and response<o:p></o:p></p>
<p class="MsoNormal"> Why have a separate credentials response field?<o:p></o:p></p>
<p class="MsoNormal"> You could add that to the Token Endpoint but how would it work for SIOP?<o:p></o:p></p>
<p class="MsoNormal"> Tobias: We tried to avoid an assertion in an assertion, but we could do that<o:p></o:p></p>
<p class="MsoNormal"> Mike: Wouldn't you want to be able to return multiple verifiable credentials?<o:p></o:p></p>
<p class="MsoNormal"> Tobias: This was about a single request from a single authority<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Federation Interop<o:p></o:p></p>
<p class="MsoNormal"> Status for last week's Federation interop was sent to the mailing list. See the e-mail:<o:p></o:p></p>
<p class="MsoNormal"> OpenID Connect Federation June 2020 interop report<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Calls<o:p></o:p></p>
<p class="MsoNormal"> Nat is going to ask the list whether to make the 4pm Pacific Time call weekly rather than bi-weekly<o:p></o:p></p>
<p class="MsoNormal"> This would work for people in New Zealand<o:p></o:p></p>
<p class="MsoNormal"> The next working group call is Thursday, July 2 at 7am Pacific Time<o:p></o:p></p>
</div>
</body>
</html>