<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;
mso-ligatures:standardcontextual;}
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;
mso-ligatures:standardcontextual;}
@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 29-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">Mark Haine<o:p></o:p></p>
<p class="MsoNormal">Petteri Stenius<o:p></o:p></p>
<p class="MsoNormal">Jeremie Miller<o:p></o:p></p>
<p class="MsoNormal">David Chadwick<o:p></o:p></p>
<p class="MsoNormal">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal">Gail Hodges<o:p></o:p></p>
<p class="MsoNormal">George Fletcher<o:p></o:p></p>
<p class="MsoNormal">Jo Vercammen<o:p></o:p></p>
<p class="MsoNormal">Joseph Heenan<o:p></o:p></p>
<p class="MsoNormal">Andrew Hughes<o:p></o:p></p>
<p class="MsoNormal">Oliver Terbu<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">JWP Virtual Interim BoF<o:p></o:p></p>
<p class="MsoNormal"> There was consensus to re-create the JOSE working group to do the work<o:p></o:p></p>
<p class="MsoNormal"> The charter was updated per discussions at the BoF - primarily simplifying the introduction<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://github.com/json-web-proofs/json-web-proofs/blob/main/charter-ietf-jose-03.md">
https://github.com/json-web-proofs/json-web-proofs/blob/main/charter-ietf-jose-03.md</a><o:p></o:p></p>
<p class="MsoNormal"> The chairs will send the meeting minutes and the charter to the JOSE list for review<o:p></o:p></p>
<p class="MsoNormal"> Timing-wise, we can't get the JOSE WG recreated before IETF 115 in London<o:p></o:p></p>
<p class="MsoNormal"> We do plan to have side meetings on the work in London<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jobs for the Future (JFF) Interop Plugfest<o:p></o:p></p>
<p class="MsoNormal"> David Chadwick reports that JFF <a href="https://www.jff.org/">
https://www.jff.org/</a> will be holding a second OpenID4VC plugfest the day before IIW<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://w3c-ccg.github.io/vc-ed/plugfest-2-2022/">
https://w3c-ccg.github.io/vc-ed/plugfest-2-2022/</a><o:p></o:p></p>
<p class="MsoNormal"> (This conflicts with the OpenID workshop on the same day)<o:p></o:p></p>
<p class="MsoNormal"> Next Generation Internet is participating<o:p></o:p></p>
<p class="MsoNormal"> <a href="https://ngiatlantic.info/">
https://ngiatlantic.info/</a><o:p></o:p></p>
<p class="MsoNormal"> Also see <a href="https://www.techuk.org/resource/crossword-security-cyber2022.html">
https://www.techuk.org/resource/crossword-security-cyber2022.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FIDO Authenticate in Seattle<o:p></o:p></p>
<p class="MsoNormal"> Is next week<o:p></o:p></p>
<p class="MsoNormal"> There's a session of OpenID content<o:p></o:p></p>
<p class="MsoNormal"> Kristina will be presenting OpenID4VC to the plenary on Wednesday<o:p></o:p></p>
<p class="MsoNormal"> The talk is free for people to attend remotely<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">OpenID Workshop<o:p></o:p></p>
<p class="MsoNormal"> The OIDF workshop will be Monday, November 14th - the day before IIW, 12:30-4:30pm in the Bay Area<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 #327: clarified the definition of response mode post - Issue #1626<o:p></o:p></p>
<p class="MsoNormal"> Brian asked for an example to be added<o:p></o:p></p>
<p class="MsoNormal"> Brian said that it's not yet defined what the response content is<o:p></o:p></p>
<p class="MsoNormal"> It's the authorization response<o:p></o:p></p>
<p class="MsoNormal"> Brian thinks that the POST name is wrong<o:p></o:p></p>
<p class="MsoNormal"> The actual OpenID Connect response is carried in an HTTP request message<o:p></o:p></p>
<p class="MsoNormal"> He thinks that post_response might be more a more indicative response model name for what actually happens<o:p></o:p></p>
<p class="MsoNormal"> Note that there's already a Form Post response mode that this could be confused with<o:p></o:p></p>
<p class="MsoNormal"> Joseph agreed with Brian's comments<o:p></o:p></p>
<p class="MsoNormal"> Joseph proposed direct_post<o:p></o:p></p>
<p class="MsoNormal"> We discussed preventing the reflection attack<o:p></o:p></p>
<p class="MsoNormal"> Brian said that there are a lot of security considerations in these cross-device flows that we need to discuss<o:p></o:p></p>
<p class="MsoNormal"> PR #325: Adds clarifying language around client identification and authentication requirements for token request<o:p></o:p></p>
<p class="MsoNormal"> Client authentication clarifications<o:p></o:p></p>
<p class="MsoNormal"> Mike suggested that Brian look at this one<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 made a number of updates<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that there's an agreement that the type should be format specific<o:p></o:p></p>
<p class="MsoNormal"> A type can now be an object and not just as a string<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that JWT-VCs could be two things<o:p></o:p></p>
<p class="MsoNormal"> A JWT without an @context in the claims<o:p></o:p></p>
<p class="MsoNormal"> A JWT where the body is valid JSON-LD<o:p></o:p></p>
<p class="MsoNormal"> Kristina and David reported that lot of productive discussions have happened on this topic<o:p></o:p></p>
<p class="MsoNormal"> PR #285: Adding batch credential endpoint: fixes #1544<o:p></o:p></p>
<p class="MsoNormal"> Oliver reported that he and Torsten have had productive discussions on the topic<o:p></o:p></p>
<p class="MsoNormal"> He plans to update the PR next week<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"> #1679: [OID4VCI] Missing client id<o:p></o:p></p>
<p class="MsoNormal"> David Chadwick talked about telling the wallet what client to use<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that this isn't specific to the pre-authorized flow<o:p></o:p></p>
<p class="MsoNormal"> Reviews requested<o:p></o:p></p>
<p class="MsoNormal"> #1607: New well known for issuing?<o:p></o:p></p>
<p class="MsoNormal"> David wants a .well-known identifier for credential issuers<o:p></o:p></p>
<p class="MsoNormal"> Joseph questions whether the issuer, in the normal OpenID sense, must be the same as the credential issuer<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that we use the identifier credential_issuer for that<o:p></o:p></p>
<p class="MsoNormal"> That's different than the OAuth issuer<o:p></o:p></p>
<p class="MsoNormal"> He asked if they should share the same "iss" value in tokens they issue<o:p></o:p></p>
<p class="MsoNormal"> George said that there's two issues<o:p></o:p></p>
<p class="MsoNormal"> How do I find the metadata<o:p></o:p></p>
<p class="MsoNormal"> It's probably not a good idea to require that the "iss" value be the same in both cases<o:p></o:p></p>
<p class="MsoNormal"> Kristina asked can we please rename initiate issuance request to credential offer request?<o:p></o:p></p>
<p class="MsoNormal"> This is related to issue #1632: Issuer metadata clarification needed<o:p></o:p></p>
<p class="MsoNormal"> Joseph said that if we're using the same IANA registry for the values, we shouldn't separate the endpoints<o:p></o:p></p>
<p class="MsoNormal"> David said that if there's only one file, each of the metadata values need to be well-defined and distinct<o:p></o:p></p>
<p class="MsoNormal"> George observed that if the credential issuer is not an OpenID Provider, then it's weird to use .well-known/openid-configuration for its metadata<o:p></o:p></p>
<p class="MsoNormal"> If we think of credential issuance as being a new API for an OpenID Provider, then it makes sense<o:p></o:p></p>
<p class="MsoNormal"> But if it's its own top-level thing, then it should have its own metadata<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that it's its own top-level thing<o:p></o:p></p>
<p class="MsoNormal"> Mike said then it should have its own metadata<o:p></o:p></p>
<p class="MsoNormal"> George said that the issuer could use the OAuth metadata name .well-known/oauth-authorization-server<o:p></o:p></p>
<p class="MsoNormal"> Torsten proposed openid-credential-issuer<o:p></o:p></p>
<p class="MsoNormal"> Mike agreed with that<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that there's rough consensus to have a separate .well-known file<o:p></o:p></p>
<p class="MsoNormal"> We need to be clear which values should be where<o:p></o:p></p>
<p class="MsoNormal"> We should follow the OpenID convention of having the .well-known be appended to the issuer path<o:p></o:p></p>
<p class="MsoNormal"> Mike said that that OAuth convention is acknowledged to be broken<o:p></o:p></p>
<p class="MsoNormal"> #1648: passing issuance initiation request by reference<o:p></o:p></p>
<p class="MsoNormal"> Reviews requested<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 is scheduled for Monday, October 17, 2022 at 4pm Pacific Time<o:p></o:p></p>
<p class="MsoNormal"> However this conflicts with Authenticate<o:p></o:p></p>
<p class="MsoNormal"> Watch the list to see whether the call will occur or be cancelled<o:p></o:p></p>
</div>
</body>
</html>