<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 10-Nov-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">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">David Chadwick<o:p></o:p></p>
<p class="MsoNormal">Andrew Hughes<o:p></o:p></p>
<p class="MsoNormal">Torsten Lodderstedt<o:p></o:p></p>
<p class="MsoNormal">Petteri Stenius<o:p></o:p></p>
<p class="MsoNormal">Tom Jones<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">IETF 115 is in London this week<o:p></o:p></p>
<p class="MsoNormal"> There's been good discussions on the use of client_id in the OAuth 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 #327: clarified the definition of response mode post - Issue #1626<o:p></o:p></p>
<p class="MsoNormal"> Merged<o:p></o:p></p>
<p class="MsoNormal"> PR #351: relaxed client id requirements for pre-authz code grant type<o:p></o:p></p>
<p class="MsoNormal"> Tobias and Torsten are discussing<o:p></o:p></p>
<p class="MsoNormal"> One idea was an error code for when receiving an anonymous request when it is not supported<o:p></o:p></p>
<p class="MsoNormal"> Torsten wants another metadata parameter indicating support for anonymous requests<o:p></o:p></p>
<p class="MsoNormal"> Mike said that bring-your-own-client_id and anonymous clients are different<o:p></o:p></p>
<p class="MsoNormal"> Torsten agreed and said that it would only be anonymous if there's no client_id at all<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that this PR is about not providing a client_id at all<o:p></o:p></p>
<p class="MsoNormal"> Mike agreed to review it in that light<o:p></o:p></p>
<p class="MsoNormal"> PR #345: Update Introduction and Overview of OpenID4VP specification to better explain the new model<o:p></o:p></p>
<p class="MsoNormal"> Kristina updated it to address Torsten's and Mike's comments<o:p></o:p></p>
<p class="MsoNormal"> Kristina and Mike are disagreeing about commas ;-)<o:p></o:p></p>
<p class="MsoNormal"> We would like to merge these PRs shortly<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"> David said that issues that can be closed are 1434, 1438, 1436<o:p></o:p></p>
<p class="MsoNormal"> #1686: op_state in pre-authz<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that you don't send the pre-authorized code to the authorization request<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that op_state is really tied to the authorization flow<o:p></o:p></p>
<p class="MsoNormal"> Torsten: op_state is used with the authorization endpoint, the pre-authorized code is used at the token endpoint<o:p></o:p></p>
<p class="MsoNormal"> Kristina asked whether both should be permitted<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that you cannot use both<o:p></o:p></p>
<p class="MsoNormal"> Torsten thinks that the pre-authorized code takes precedence<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that she doesn't think we should be the ones to define the precedence<o:p></o:p></p>
<p class="MsoNormal"> Torsten agreed to do a PR<o:p></o:p></p>
<p class="MsoNormal"> #1648: passing issuance initiation request by reference<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that op_state becomes huge because it's an encrypted token<o:p></o:p></p>
<p class="MsoNormal"> It blows up the QR code<o:p></o:p></p>
<p class="MsoNormal"> Kristina asked if there could be a way to pass it by reference<o:p></o:p></p>
<p class="MsoNormal"> Torsten doesn't see a need for passing it by reference<o:p></o:p></p>
<p class="MsoNormal"> The op_state is created by the issuer and consumed by the issuer<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that we'd be forcing the wallet to fetch a huge block of binary data and pass it to the authorization request<o:p></o:p></p>
<p class="MsoNormal"> Torsten suggested having access to the state happen within the AS<o:p></o:p></p>
<p class="MsoNormal"> Kristina said that this is about having the AS be able to be stateless<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that using a request_uri introduces state at the AS<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that the value of the op_state could be a database table index, since it's opaque to others<o:p></o:p></p>
<p class="MsoNormal"> #1687: Do we need to support signed issuer initiated issuance requests?<o:p></o:p></p>
<p class="MsoNormal"> Torsten thought that signing the request would authenticate the requester<o:p></o:p></p>
<p class="MsoNormal"> David said that you'd have to social engineer the user to get them to go to the wrong site in the first place<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that signing would let the request be matched against a list of authorized issuers<o:p></o:p></p>
<p class="MsoNormal"> Tom was skeptical of there being a list of authorized issuers<o:p></o:p></p>
<p class="MsoNormal"> Mike agreed that signing the request would enable authenticating the requester<o:p></o:p></p>
<p class="MsoNormal"> Torsten proposed asking Daniel Fett for a security assessment<o:p></o:p></p>
<p class="MsoNormal"> #1570: Rename Initiation issuance Request to..? Credential Offer?<o:p></o:p></p>
<p class="MsoNormal"> We discussed whether we can find an easier-to-say term than Issuer Initiated Request (IIR)<o:p></o:p></p>
<p class="MsoNormal"> We want people to understand that this flow reverses roles<o:p></o:p></p>
<p class="MsoNormal"> It's a request for the issuer to make a request<o:p></o:p></p>
<p class="MsoNormal"> Mike called it a "Request Request" on the call<o:p></o:p></p>
<p class="MsoNormal"> People are encouraged to suggest better names<o:p></o:p></p>
<p class="MsoNormal"> #1720: define user identifier when proof is signed using JWK<o:p></o:p></p>
<p class="MsoNormal"> It would be a JWK Thumbprint URI<o:p></o:p></p>
<p class="MsoNormal"> Kristina will write a PR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">PRs:<o:p></o:p></p>
<p class="MsoNormal"> PR #255: Determining if one party may be able to trust a second party.<o:p></o:p></p>
<p class="MsoNormal"> David explained the problem on the call<o:p></o:p></p>
<p class="MsoNormal"> Mike said that this is meta-protocol information<o:p></o:p></p>
<p class="MsoNormal"> It's not clear that we want to pass this at runtime<o:p></o:p></p>
<p class="MsoNormal"> Torsten said that it's not clear why you would trust the trust information passed to the request<o:p></o:p></p>
<p class="MsoNormal"> Torsten disagreed with the term "trust framework"<o:p></o:p></p>
<p class="MsoNormal"> David said that it's now "trust method"<o:p></o:p></p>
<p class="MsoNormal"> David said that each trust method would determine the payload for its trust method information<o:p></o:p></p>
<p class="MsoNormal"> Torsten wasn't in favor of doing this<o:p></o:p></p>
<p class="MsoNormal"> He said that SIOP already specifies how to determine this information<o:p></o:p></p>
<p class="MsoNormal"> Kristina plans to close the PR to consolidate the conversation in the issue<o:p></o:p></p>
<p class="MsoNormal"> The issue is #1551: Administrative Trust in the RP<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"> #1707: cryptographic_binding_methods_supported Support for listing specific DID methods?<o:p></o:p></p>
<p class="MsoNormal"> People thought this is reasonable<o:p></o:p></p>
<p class="MsoNormal"> #1689: Encoding of Issuer Initiated Issuance Requests<o:p></o:p></p>
<p class="MsoNormal"> We discussed possible alternative encodings: form-url, base64url<o:p></o:p></p>
<p class="MsoNormal"> We are currently using a JSON object passed form-url encoding<o:p></o:p></p>
<p class="MsoNormal"> Mike thinks the current approach is fine<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"> We plan to cancel the SIOP call next week because of IIW<o:p></o:p></p>
</div>
</body>
</html>