<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think these are the notes for 13 Oct</p>
<p>David<br>
</p>
<div class="moz-cite-prefix">On 13/10/2022 17:03, Mike Jones via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SJ0PR00MB13174BF8F850113101D35DE7F5259@SJ0PR00MB1317.namprd00.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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;}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;}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]-->
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">
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/" moz-do-not-send="true"
class="moz-txt-link-freetext">
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/"
moz-do-not-send="true" class="moz-txt-link-freetext">
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/" moz-do-not-send="true"
class="moz-txt-link-freetext">
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"
moz-do-not-send="true" class="moz-txt-link-freetext">
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/"
moz-do-not-send="true" class="moz-txt-link-freetext">
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"
moz-do-not-send="true">
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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>