
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div>Attendees:</div><br class="Apple-interchange-newline"></div><div>Joseph Heenan</div><div>Kristina Kasuda</div><div>Torsten Lodderstedt</div><div>David Waite</div><div>Brian Campbell</div><div>Oliver Terbu</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>PR427</div><div><br></div><div>Torsten is happy with any name for the parameter.</div><div><br></div><div>Brian prefers client_id_scheme</div><div><br></div><div>Torsten said what we picked should be applicable to OID4VP, OID4VCI, SIOP and other use cases, and he will discuss it with OAuth WG at IETF Yokohama.</div><div><br></div><div>Brian agrees that it’s a larger thing than VP.</div><div><br></div><div>Torsten to remove mention of TRAIN from this PR.</div><div><br></div><div>David Waite raised the issue that if URLs are used then ASs must not treat the same URL when used in a different scheme/format/trustmethod must not be considered the same client by the AS. There was some discussion about how the AS should treat the same client_id being used in different schemes - should AS reject, or should the AS just treat them as separate clients. Federation may not be the only method that uses https urls for the client id. Consensus on the latter, AS must treat as separate clients.</div><div><br></div><div>Some discussion about whether we should essentially have a structured/parameterised/‘rich' client_id instead. Discussion to continue next week.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/pull-requests/451">https://bitbucket.org/openid/connect/pull-requests/451</a><br></div><div><br></div><div>Consensus to use ‘input_descriptor’ instead of Input Descriptor.</div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/issues/1696/is-proof-type-flexibility-needed">https://bitbucket.org/openid/connect/issues/1696/is-proof-type-flexibility-needed</a></div><div><br></div><div>Torsten points out that there is a pull request on cwt proof type ( <a href="https://bitbucket.org/openid/connect/pull-requests/384">https://bitbucket.org/openid/connect/pull-requests/384</a> ) and if this is accepted then yes, this type of flexibility is needed.</div><div><br></div><div>Torsten also said there are proof of possession methods that don’t use a traditional signature and hence can’t be represented in JWT.</div><div><br></div><div><br></div><div><br></div><div>Kristina asked about taking OID4VCI spec to first implementers draft. No one on call objected.</div><div><br></div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/pull-requests/443">https://bitbucket.org/openid/connect/pull-requests/443</a> - JSONPath security considerations</div><div><br></div><div>David Waite suggested we ask the JSONPath IETF working group if they already have a profile that solves the security issues.</div><div><br></div><div><br></div></body></html>