
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Adding my responses as well<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2021, at 5:18 AM, Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""></span><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><font face="Calibri, sans-serif" style="font-size: 11pt;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>></font></div></div></blockquote>>snip<br class=""><blockquote type="cite" class=""><div class=""><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><font face="Calibri, sans-serif" style="font-size: 11pt;" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">Here is my detailed feedback: </span></font></div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;"><div class=""><br class=""></div><div class="">- "Relying Parties typically cannot pre-establish registration with a Self-Issued OP, as each End-user might be represented by a different, locally-controlled Self-Issued OP instance. This specification extends the authentication request with a mechanism with additional dynamic registration techniques for feature negotiation.“<br class=""><br class="">Other models are possible, e.g. all instances of a wallet app sharing the same RP registration data. This should be mentioned in the spec. </div><div class=""><span style="color: rgb(12, 100, 192);" class="">-> below text added in this scope section. <span style="margin: 0px;" class=""><span style="margin: 0px;" class="">Still need to think how to add this to other sections such as the registration metadata section.</span></span><br class=""><span style="margin: 0px;" class=""></span></span></div><div class=""><span style="color: rgb(12, 100, 192);" class="">"In another model, when all instances of Sel-Issued OPs share the same RP registration data, it is possible for the RPs to pre-establish registration with that set of Self-Issued OPs."</span></div><div class=""><font color="#0c64c0" class="">Assuming that the method used by the RP in this case would be out-of-band or Dynamic Client Registration..?</font></div></div></div></blockquote><div><br class=""></div><div>I consider there several variants of relationships between the RP and OP; either you have a pre-existing/out-of-band relationship or a dynamically established relationship based on resolved OP metadata and one of:</div><div><br class=""></div><div>1. dynamic client registration</div><div>2. resolved RP metadata</div><div>3. resolved RP keys, with non-credential RP metadata via a “registration” parameter in a signed request</div><div>4. client_id = redirect_uri with spec-synthesized RP metadata, or spec-whitelisted values in a non-signed “registration” parameter"</div><div><br class=""></div><div>There’s not really a reason any of these are exclusive to OP or SIOP support, but there are compromises - for instance, DCR would require a hosted shared component for SIOP use.</div><div><br class=""></div><div>I somewhat hope that since publishing a native app requires you to have a web presence per App Store rules (and an interactive web app will as well), we can eliminate #4 and possibly #3.</div><div><br class=""></div><div>>snip</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;"><div class="">- "## Relying Party Registration“<br class=""><br class="">The new revision supports entity statements and DIDs as only client id. This mandates signed requests for SIOP, which makes SIOP significantly more complex to implement. How is this justified?</div><div class=""><br class=""></div><div class="">I personally would feel better to retain the simple "client id is redirect uri“ approach as third option. </div><div class=""><span style="color: rgb(12, 100, 192);" class="">-> The intention was not to remove "client id is redirect uri“ option. I added the text clarifying that when the request is not signed, "client id is redirect uri“.</span></div><div class=""><font color="#0c64c0" class="">-> I also added a summary of the options in the very beginning of the registration and discovery section.</font></div></div></div></blockquote><div><br class=""></div>First, if automatic client registration requires a signed request, we need to figure out why that requirement is there and potentially push to remove it. To my eyes against the current spec, the trade-offs between signed and unsigned requests are identical with or without federation - so mandating signed requests should be a policy the authority root sets, not the spec.<br class=""><div><br class=""></div>Separately, I’m fine if the client_id = redirect_uri allows no registration metadata override, or if someone goes through the effort of defining a whitelist of which registration metadata parameters are usable within an appropriate attacker model. Limiting the attacker model would be key there - there are plenty of metadata values like ‘client_name’ and ‘logo_uri’ which I would not display even from entity statements, but that is a reputitional impersonation and not a protocol-level one.</div><div><br class=""></div><div>We will however need to differentiate now whether the client_id is meant to be synthetic metadata (based on the value being a redirect URI) or hosted metadata (resolve via .well-known or some other mechanism) for https schemes - we will have two uses within the same namespace.</div><div><br class=""></div><div>For that reason, I _hope_ we don’t need client_id = request_uri going forward, because the interplay with other client_id values and the registration data attacker model aspects make it messy, and I really don’t want to risk the same client_id being interpreted as an entity statement or a redirect_uri based on some transient web hosting issue - especially if that grants an opportunistic attacker to be able to specify their own registration data inline.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;"><div class="">- "# Self-Issued OpenID Provider Response {#siop-authentication-response}" does not describe handling of SIOP responses with other than "<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fself-issued.me%2Fv2&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ce8687928bf7848967c2c08d9a1e912f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637718844724683333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=l1sGYdWOSvIDqjHKCJDSUJcai47TQ%2FVTAKL9hCXvVeE%3D&reserved=0" originalsrc="https://self-issued.me/v2" shash="aJEN6ynRQfK/8VPm7faR6Vypv501EXflB1DfszPI7RkEv3GMiexnrXl+pinMzz2cwo9rczpHqEhyZBHN1fKvIuFsgteGMGxcRnuOGaR/MYiJZyMF3OK5ytSzheXCtjSLCCoSKQnWrouPx5+6vnAlB1JHIvZvmMRtXOGIz/2ecKU=" class="">https://self-issued.me/v2</a>" iss values<br class=""></div></div></div></blockquote><div><br class=""></div>I believe this is an ongoing point for discussion - whether responses are differentiated by issuer metadata or if the id_tokens themselves are stamped in some way to distinguish them from non-SIOP id_tokens.</div><div><br class=""></div><div>I feel we can do better than having “iss” being the stamp on id_tokens to show them as being self-issued, especially since it does not buy us anything with regards to compatibilty - even a OIDC core implementation which used the old self-issued URL as the issuer to differentiate will not recognize the new self-issued URL.</div><div><br class=""></div><div>>snip<br class=""><blockquote type="cite" class=""><div class=""><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;"><div class="">- "1. The RP MUST validate the signature of the ID Token. When Subject Syntax Type is `jkt`, …" </div><div class=""><br class=""></div><div class="">It ist unclear to me how the RP determines what subject syntax type is used. Is it the existence of the „sub_jwk“ claim in the id token? </div><div class=""><span style="color: rgb(12, 100, 192);" class="">-> Currently, if subject syntax type is did, sub=did:<method name>:<identifier>; if subject syntax type is jwk, sub_jwk is present. I added a text to this meaning, but feedback welcome if this is enough and makes sense.</span></div></div></div></blockquote><div><br class=""></div><div>A previous proposal which I think is still worth proposing is whether we are willing to make a clean break with sub_jwk, and instead define a JWK URI scheme.</div></div><div><br class=""></div><div>Then the SIOP limitation becomes that the subject must be a URI and that the URI can be resolved to a key or set of keys. The processing logic gets cut significantly as abstractly the step is working the same way. Syntax types are defined exclusively as a registration negotiation item.</div><div><br class=""></div><div>This also means that a client-id could be a JWK URI, which makes it relatively simple for clients willing to do signed requests to embed their effective registration metadata with zero hosted metadata.</div><div><br class=""></div><div>-DW</div></body></html>