<html 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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Phil: which statement do you not agree with?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 2/14/18, 11:26 AM, someone claiming to be "Openid-specs-risc on behalf of Phil Hunt via Openid-specs-risc" <<a href="mailto:openid-specs-risc-bounces@lists.openid.net">openid-specs-risc-bounces@lists.openid.net</a>
on behalf of <a href="mailto:openid-specs-risc@lists.openid.net">openid-specs-risc@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in">I don’t agree with Dick here. SET delivery *should* be straight forward. We are passing URL safe strings to one another - lets not make this any more complex.
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">There is a diverse set of security configurations in all of the profile communities. This is not a RISC is somehow specialized from the rest of the world. Within RISC our own usage for implicit involves a lot
of web applications that do no federation at all. They don’t use oauth nor OpenID (much as we would like them to). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I have come to the conclusion that both RISC and SECEVENTs cannot make general assumptions about security environments. We can assume they will deploy HTTP the way they want to. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">—>The approach that SECEVENTs should take, is that delivery of SETS is a simple HTTP service and any secure HTTP configuration people want to use is acceptable. SCIM went through this same debate. You’ll notice
while SCIM reviews some of the common security authorization techniques (e.g. OAuth) it stays silent on recommendations. The proof in the market-place is that this has not lead to interoperability problems for SCIM. Why? Because people use what is common
practice in their environments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">So what should we do with the profile draft???<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I think it is reasonable for now, to define it as the "testing profile" for RISC. In a testing profile, it is fine to test out assumptions and simplifications to see if they are universal. We must still keep in
mind that many who can’t pilot right now may still have different requirements. E.g. Are there any implicit participants in the pilot?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">As a testing profile, it also reminds participants that the drafts are subject to change as SECEVENTs evolves. But more importantly, it provides real implementation experience data from RISC to feed back into SECEVENTs
without being seen as an initiative to fork SECEVENTs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I want to make sure we get the SECEVENTs group working and in particular, work on the subject identification draft and get that done alone with the other items. —> Marius, we should get the chairs to amend the charter
in this regard.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Phil<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Oracle Corporation, Identity Cloud Services Architect<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">@independentid<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"><a href="http://www.independentid.com">www.independentid.com</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"><a href="mailto:phil.hunt@oracle.com">phil.hunt@oracle.com</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in">On Feb 10, 2018, at 9:34 AM, Phil Hunt <<a href="mailto:phil.hunt@oracle.com">phil.hunt@oracle.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">I don’t think this is a scim is different than risc is different than xxx issue. </span>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">I do think there are many different environments within risc itself. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">Oracle has Palerra which works with web applications to detect and issue events. It has nothing to do with connect. — yet the objective would be to send events
back to IDPs. While many consume id tokens, not all do. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">There are also implicit federation cases (email, telephone) which have nothing to do with connect. While some have oauth enabled mail, most do not. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">The conversation at Cisco gave me pause because all of these cases seemed excluded by assuming oauth token and oidc systems are present. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">I have concluded that the security (eg authorization header) config is highly variable when it comes to oauth etc. As much as I would like to impose a solution,
the only one that seems repeatable is old fashioned mutual tls for server to server comms. Since any server can generated self signed certs. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">From my perspective just within risc we do not have a good solution other than manual config. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">I fear that this will add to the configuration hassles we already have that were trying to he addressed with fastfed. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Helvetica">Phil<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<span style="font-size:9.0pt;font-family:Helvetica"><br>
On Feb 5, 2018, at 1:11 PM, Hardt, Dick <<a href="mailto:dick@amazon.com"><span style="color:purple">dick@amazon.com</span></a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in">On 2/5/18, 12:38 PM, someone claiming to be "Openid-specs-risc on behalf of Marius Scurtescu via Openid-specs-risc" <<a href="mailto:openid-specs-risc-bounces@lists.openid.net"><span style="color:purple">openid-specs-risc-bounces@lists.openid.net</span></a><span class="apple-converted-space"> </span>on
behalf of<span class="apple-converted-space"> </span><a href="mailto:openid-specs-risc@lists.openid.net"><span style="color:purple">openid-specs-risc@lists.openid.net</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><a name="_MailOriginalBody">On Mon, Feb 5, 2018 at 11:29 AM, Phil Hunt <</a><a href="mailto:phil.hunt@oracle.com" target="_blank"><span style="mso-bookmark:_MailOriginalBody"><span style="color:purple">phil.hunt@oracle.com</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">>
wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">Marius,<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">Should discovery not be part of SECEVENTs? <o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">Given there is not one in SecEvent now, it needs to be profiled in RISC<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"><snip><o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">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? <o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">I think “need” is too strong. A single management API is desired.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">Another aspect is that the management requirements of RISC, SCIM, OIDC etc. so far look quite different.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">RISC has specific needs, and with a concrete API, there can more easily be a discussion on commonalities, or lack thereof with other SecEvent profiles.<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody">/Dick<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>