<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">Spec Call Notes 8-Apr-21<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Filip Skokan<o:p></o:p></p>
<p class="MsoNormal">Vladimir Dzhuvinov<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal">George Fletcher<o:p></o:p></p>
<p class="MsoNormal">Adam Lemmon<o:p></o:p></p>
<p class="MsoNormal">Tim Cappalli<o:p></o:p></p>
<p class="MsoNormal">Bjorn Hjelm<o:p></o:p></p>
<p class="MsoNormal">Oliver Terbu<o:p></o:p></p>
<p class="MsoNormal">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">Tom Jones<o:p></o:p></p>
<p class="MsoNormal">Joseph Heenan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">OpenID Connect Federation Draft<o:p></o:p></p>
<p class="MsoNormal">              Roland reported on the Federation Draft progress<o:p></o:p></p>
<p class="MsoNormal">              We did three interop events last year<o:p></o:p></p>
<p class="MsoNormal">                           There are three independent implementations - by Vladimir Dzhuvinov, Henri Mikkonen, and Roland Hedberg<o:p></o:p></p>
<p class="MsoNormal">                           The specification has been iteratively updated to address issues found<o:p></o:p></p>
<p class="MsoNormal">              People had been able to largely implement in an interoperable fashion<o:p></o:p></p>
<p class="MsoNormal">              Issues from Torsten and Brian were also discussed and addressed<o:p></o:p></p>
<p class="MsoNormal">              Leif Johansson pointed out a remaining dependence upon Web PKI<o:p></o:p></p>
<p class="MsoNormal">                           jwks_uri uses Web PKI<o:p></o:p></p>
<p class="MsoNormal">                           It can be avoided using entity statements with "jwks", but that interferes with key rotation<o:p></o:p></p>
<p class="MsoNormal">              Or we can introduce signed_jwks_uri (which apparently we discussed ~2 years ago)<o:p></o:p></p>
<p class="MsoNormal">                           This is in Roland's code<o:p></o:p></p>
<p class="MsoNormal">                           Roland has asked Vladimir and Henri to also add it<o:p></o:p></p>
<p class="MsoNormal">                           Then they'll do interop on the new feature<o:p></o:p></p>
<p class="MsoNormal">                           John recalls the signed jwks_uri discussion<o:p></o:p></p>
<p class="MsoNormal">                           John asked about how to trust the signature<o:p></o:p></p>
<p class="MsoNormal">              Vladimir asked if there had been thoughts of using the Accept header<o:p></o:p></p>
<p class="MsoNormal">                           John said that we have used metadata parameters instead of that design pattern<o:p></o:p></p>
<p class="MsoNormal">              Mike asked with what key you sign the keys<o:p></o:p></p>
<p class="MsoNormal">                           Roland said that the entity statements are self-signed<o:p></o:p></p>
<p class="MsoNormal">                           But you're trusting  it because the key is protected by the trust chain<o:p></o:p></p>
<p class="MsoNormal">              Roland will create a spec update adding signed_jwks_uri<o:p></o:p></p>
<p class="MsoNormal">                           Mike and John will review<o:p></o:p></p>
<p class="MsoNormal">                           Roland will ask Vlad and Henri to ask review<o:p></o:p></p>
<p class="MsoNormal">              Next Steps<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that we could either do another Implementer's Draft or take the spec to Final status<o:p></o:p></p>
<p class="MsoNormal">                           John said that he thought we should do another Implementer's Draft<o:p></o:p></p>
<p class="MsoNormal">                                         He wants to see the near-final draft be widely circulated<o:p></o:p></p>
<p class="MsoNormal">                           Roland reports that Leif is involved in a project that may also be building or deploying it<o:p></o:p></p>
<p class="MsoNormal">                                         Roland will check in with him<o:p></o:p></p>
<p class="MsoNormal">                           John reports that the spec has come up on Internet2 calls<o:p></o:p></p>
<p class="MsoNormal">                           Vladimir reports that there are no real deployments yet - just interoperating implementations<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Claims for Verifiable Credentials Objects<o:p></o:p></p>
<p class="MsoNormal">              Mike summarized some recent discussions on using W3C Verifiable Credential objects with JWTs<o:p></o:p></p>
<p class="MsoNormal">              The VC spec defines "vc" and "vp" claims, which are used as part of the W3C-define JWT representations<o:p></o:p></p>
<p class="MsoNormal">                           The values of these claims are not complete Verifiable Credential or Verifiable Presentation objects<o:p></o:p></p>
<p class="MsoNormal">              The W3C VC spec defines representations for four things, which are the combinations of two sets of two things each:<o:p></o:p></p>
<p class="MsoNormal">                           JWT and JSON-LD representations<o:p></o:p></p>
<p class="MsoNormal">                           Verifiable Credential and Verifiable Presentation representations<o:p></o:p></p>
<p class="MsoNormal">              Mike sent a proposal to the working group defining four JWT claims for these four kinds of objects<o:p></o:p></p>
<p class="MsoNormal">                           vc_jwt, vp_jwt, vc_ld, and vp_ld<o:p></o:p></p>
<p class="MsoNormal">              John asked where these would be used<o:p></o:p></p>
<p class="MsoNormal">                           They could be used in the ID Token, in UserInfo Endpoint responses, and in other sets of IANA JWT claims<o:p></o:p></p>
<p class="MsoNormal">              John asked whether we should overload claims, using the same claims for JWT and JSON-LD representations<o:p></o:p></p>
<p class="MsoNormal">                           People were opposed to overloading<o:p></o:p></p>
<p class="MsoNormal">              Mike tried to respond to Tom's e-mail comment about instead using claim names defined for particular use cases<o:p></o:p></p>
<p class="MsoNormal">                           Tom talked about ID Proofing versus Authentication Proofing<o:p></o:p></p>
<p class="MsoNormal">                           Tom said that healthcare people have turned data structures into strings and put them in amr values<o:p></o:p></p>
<p class="MsoNormal">                           Oliver says that VCs contain a type property<o:p></o:p></p>
<p class="MsoNormal">                           Kristina said that VCs and VPs are becoming part of identity for some use cases<o:p></o:p></p>
<p class="MsoNormal">                           Tom objects to having generic claims, rather than specific claims<o:p></o:p></p>
<p class="MsoNormal">                           Tim said that the VP should be in response to a request with a specific set of requirements<o:p></o:p></p>
<p class="MsoNormal">                           Tim supports having generic claims<o:p></o:p></p>
<p class="MsoNormal">                           Mike reported on RFC 7800 "cnf" claim naming and the possibility of multiple claim names here too<o:p></o:p></p>
<p class="MsoNormal">                                         Just like use cases can define other claims with the "cnf" syntax,<o:p></o:p></p>
<p class="MsoNormal">                                         the same could be done here, when needed to distinguish between multiple kinds of W3C VC objects<o:p></o:p></p>
<p class="MsoNormal">              George asked whether we want to have all claims be returned in VCs and VPs<o:p></o:p></p>
<p class="MsoNormal">                           Mike said, no, that's not what we're doing<o:p></o:p></p>
<p class="MsoNormal">                           Tim said that Presentation Exchange has paths to say where claims should to go<o:p></o:p></p>
<p class="MsoNormal">                                         <a href="https://identity.foundation/presentation-exchange/">
https://identity.foundation/presentation-exchange/</a><o:p></o:p></p>
<p class="MsoNormal">                           Tim said that that some use cases will use one or the other<o:p></o:p></p>
<p class="MsoNormal">                           Kristina said she views these objects as claims at the same level of things like e-mail<o:p></o:p></p>
<p class="MsoNormal">                           George said that he wants to ask for a Mobile Driver's License claim in a format that he can process it<o:p></o:p></p>
<p class="MsoNormal">                                         He needs to know the format that the claim will be returned in<o:p></o:p></p>
<p class="MsoNormal">                                         Tom reports that Mobile Driver's Licenses will be in ISO 18013-5 format - not JWTs or VCs<o:p></o:p></p>
<p class="MsoNormal">                           John said that there are already four JWT claims formats - JSON, Normal JWT, Aggregated, and Distributed<o:p></o:p></p>
<p class="MsoNormal">                           George wants there to be metadata about claims<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that Edmund's Claims Aggregation draft does enable claims to be requested in different structures<o:p></o:p></p>
<p class="MsoNormal">                           <a href="https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md">
https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md</a><o:p></o:p></p>
<p class="MsoNormal">                           Oliver said that registering a small set of claims seems like a next step<o:p></o:p></p>
<p class="MsoNormal">                           George wants to be able to request claims in particular formats, and with particular groupings<o:p></o:p></p>
<p class="MsoNormal">                                         That means that would have to work on richer claims requests syntax<o:p></o:p></p>
<p class="MsoNormal">              Mike said that he's trying to first solve the simple cases<o:p></o:p></p>
<p class="MsoNormal">                           George said that this doesn't preclude more complicated cases<o:p></o:p></p>
<p class="MsoNormal">                           Mike said he plans to write the tiny spec and explicitly say what it's not doing<o:p></o:p></p>
<p class="MsoNormal">                           Tom said that you can't ask all Claims Providers to support VC formats<o:p></o:p></p>
<p class="MsoNormal">                           Tom said that he might also write up a parallel spec for generic JOSE claims<o:p></o:p></p>
<p class="MsoNormal">                                         John said that we already have that: aggregated and distributed claims<o:p></o:p></p>
<p class="MsoNormal">                           Tom wants to try to remove things from front-end processing<o:p></o:p></p>
<p class="MsoNormal">                           John asks whether we want an external dictionary for VCs like we have for aggregated and distributed claims<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Browser Special Call Report<o:p></o:p></p>
<p class="MsoNormal">              We ran out of time for this<o:p></o:p></p>
<p class="MsoNormal">              Tim did send notes from the call to the list<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">              We ran out of time for this<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 regular Connect call is on Monday, April 12th, 2021 at 4pm Pacific Time<o:p></o:p></p>
</div>
</body>
</html>