<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 5, 2018 at 11:29 AM, Phil Hunt <span dir="ltr"><<a href="mailto:phil.hunt@oracle.com" target="_blank" class="gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">phil.hunt@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Marius,<div><br></div><div>Thanks for the draft.</div><div><br></div><div>Some questions:</div><div><br></div><div>Section 2 - Subject Identifier.</div><div><br></div><div>How is the JSON object conveyed in SET?  Is it in the payload identified as an attribute?  Is it the value of “sub” in the top level?</div></div></blockquote><div><br></div><div>Good point. It is meant as event payload, the event types spec has examples. This should be made explicit and an example should be provided in the RISC profile.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Section 3 - Discovery</div><div><br></div><div>There is a lot of metadata that to me is not service provider wide - but is stream specific. Example, signer certificates may be assigned in pairwise or domain specific fashion.  This may be of particular concern to tenancy based service providers.</div></div></blockquote><div><br></div><div>Key resolution is very similar to OIDC, it is based on issuer, hence not stream specific. Not saying it cannot be, just that this is the approach. Other profiles can choose different ways.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Included in the discovery should be some discussion of authentication and authorization.</div></div></blockquote><div><br></div><div>Do you have a concrete suggestion? The RISC profile addresses authn and there was no need for anything in the discovery doc.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Should discovery not be part of SECEVENTs?  </div></div></blockquote><div><br></div><div>Could be. Several parts of this profile could theoretically be moved to secevent. First I think it makes sense to see a complete and consistent solution and then if the secevent working group shows interest we can look at splitting parts out.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Note also, an issue came up in OAuth Metadata and Connect well-known paths - Mike can probably explain. See:</div><div><a href="https://www.ietf.org/mail-archive/web/oauth/current/msg17745.html" target="_blank" class="gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">https://www.ietf.org/mail-<wbr>archive/web/oauth/current/<wbr>msg17745.html</a></div></div></blockquote><div><br></div><div>Interesting. Do you have a concrete suggestion how discovery could work?</div><div><br></div><div>For example, for:</div><div>GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1</div><div>Host: <a href="http://example.com">example.com</a> </div><div><br></div><div>The actual issuer URL is: <a href="https://example.com/issuer1/">https://example.com/issuer1/</a></div><div><br></div><div>Is the issuer URL the same for:</div><div><div>GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1</div><div>Host: <a href="http://example.com">example.com</a></div></div><div>?</div><div><br></div><div>If yes, is this how discovery should work:</div><div>{host of issuer} + "<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">/.well-known/risc-configuration</span>" + {path of issuer}</div><div>?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Section 4 - we had discussions in Singapore that a majority of attendees indicated they need a multi-profile management API.  Why does the RISC document have one? </div></div></blockquote><div><br></div><div>We went back and forth on this quite a bit. The current management API proposes only one stream between one transmitter and one receiver. Allowing multiple relieve some receivers of the need to implement a dispatcher. We can definitely pick up that discussion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I understand there is some pressure for the pilot, but it would seem to me that the pilot can be done through manual administration and should not require a management API (except for error checking) at this time.</div></div></blockquote><div><br></div><div>The pressure is to have a concrete implementation ready proposal so we can have a discussion in the concrete and to see all details. The pilot is not the pressure (and as you mention, not really needed for a pilot).</div><div><br></div><div><br></div><div>Thanks for the feedback,</div><div>Marius</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div><span class="gmail-m_1627241325679796591Apple-style-span" style="border-collapse:separate;line-height:normal"><div style="word-wrap:break-word"><div><div><div>Phil</div><div><br></div><div>Oracle Corporation, Identity Cloud Services Architect</div><div>@independentid</div><div><a href="http://www.independentid.com" target="_blank" class="gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">www.independentid.com</a></div></div></div></div></span><a href="mailto:phil.hunt@oracle.com" target="_blank" class="gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">phil.hunt@oracle.com</a></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<div><br><blockquote type="cite"><div>On Feb 2, 2018, at 2:25 PM, Marius Scurtescu via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank" class="gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">openid-specs-risc@lists.<wbr>openid.net</a>> wrote:</div><br class="gmail-m_1627241325679796591Apple-interchange-newline"><div><span id="gmail-m_1627241325679796591cid:E834D9E0-7A27-4F57-ADFB-7729BA817263@vn.shawcable.net"><risc-secevent.pdf></span></div></blockquote></div><br></div></div></blockquote></div><br></div></div>