<html xmlns:v="urn:schemas-microsoft-com:vml" 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:"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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Mike Schwartz - your statement that " We had two comments--both negative--and neither one really discussed " is incorrect. Indeed, the editors acknowledged your and Filip's comments in their reply
<a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006794.html">
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006794.html</a> and agreed to address them in the next revision. That will happen after the current vote to grant IPR protections to implementers of the specification concludes. The purpose
of this vote is described in the reply <a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006795.html">
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006795.html</a>, and indeed, in the public blog post about the IPR review
<a href="http://openid.net/2018/06/08/public-review-period-for-openid-connect-federation-specification-started/">
http://openid.net/2018/06/08/public-review-period-for-openid-connect-federation-specification-started/</a>.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thank you again for taking the time to review the specification.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> -- Mike<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">P.S. A vote against Implementer's Draft status essentially boils down to "I do not want developers to have IPR protections when implementing this draft".<span style="color:#002060"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net>
<b>On Behalf Of </b>Jeff LOMBARDO via Openid-specs-ab<br>
<b>Sent:</b> Wednesday, July 18, 2018 9:17 AM<br>
<b>To:</b> mike@gluu.org<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from the Federation Spec Vote<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Hi Mike,</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">From my short interaction with <span style="background:white">Connect Federation spec, I must say that for a shorter text it looks more complex that other specs. But there is a strong need for a Federation
of OP if we want to achieve an efficient and better SIIdP strategy (IMO).</span><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;background:white">Funny thing is your derivative / summarized text from the Draft makes it clearer for me. So I will ABSTAIN to prove I read the spec, saw a trend there/good people trying to solve this, and
admit my incapacity to fully appreciate the Draft to choose instead APPROVE beyond a reasonable doubt.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;background:white">JF</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Le mar. 17 juill. 2018, à 22 h 31, Mike Schwartz via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> a écrit :<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">OpenID Connect Group,<br>
<br>
I got an email notification today that the vote for the Implementer's <br>
Draft of the Connect Federation spec is active now.<br>
<br>
There has been no discussion of this spec on the list. We had two <br>
comments--both negative--and neither one really discussed. It reminds of <br>
the FCC vote on Net Neutrality... all comments negative... APPROVE!<br>
<br>
I do not want to implement this spec, which is saying a lot because Gluu <br>
is keenly interested to see multi-party federations move forward for <br>
OpenID Connect.<br>
<br>
I think we need more discussion, more community involvement, more <br>
outreach to stakeholders, and more consensus before we move to the next <br>
step.<br>
<br>
If you have not read and considered this spec, I would ask you to at <br>
*ABSTAIN*.<br>
<br>
If you find the following three sections totally incomprehensible, I <br>
would ask you to *OBJECT*. I think this fails the mission of Connect <br>
which is to make guidelines which are developer friendly.<br>
<br>
--------------------------<br>
1. BASIC (!) Components:<br>
--------------------------<br>
To describe Compounded Metadata Statements, we need a way of describing <br>
the different components in such a statement. These are the basic <br>
components:<br>
<br>
ms_X<br>
<br>
Metadata Statement signing request by X without signing keys and signed <br>
metadata statements.<br>
SK[X]<br>
<br>
Signing keys that belong to X<br>
X(MS)<br>
<br>
Metadata Statement signed by X<br>
A(ms_B + SK[B])<br>
Using these basic components, we can now describe a simple signed <br>
Metadata Statement as:<br>
<br>
(ms_C + SK[C])<br>
(ms_C + SK[C] + A(ms_B + SK[B]))<br>
Creating a compounded metadata statements involves adding previously <br>
signed metadata statements to the request before signing it. So, if we <br>
start off with C sending this signing request to B,<br>
<br>
B(ms_C + SK[C) + A(ms_B + SK[B]))<br>
This is the resulting compounded metadata statement:<br>
<br>
--------------------------------------------<br>
2. Constructing a Signed Metadata Statement<br>
--------------------------------------------<br>
<br>
Constructing a Signed Metadata Statement<br>
These are the steps that are performed to construct a signed metadata <br>
statement. A metadata signing request may be about one specific entity <br>
or a group of similar entities.<br>
<br>
The requester constructs a signing request by collecting the necessary <br>
relying party or provider metadata as described in Section 3.<br>
If this is about the top most metadata statement (ms_0) then no metadata <br>
statement will be added to the metadata statement. If it is a more <br>
specific metadata statement (ms_1...n) then more general metadata <br>
statement/-s MUST be added. Dependent on setup the metadata statement <br>
can be added by the requester or the signer.<br>
The metadata statement is transported to the signing party. In the case <br>
of ms_0 this MUST be the FO. If it is ms_1 it is the L0Req. If it is <br>
ms_2 it is the L1Req and so on.<br>
The signing party verifies the information in the metadata statement, <br>
modifies and/or adds more information according to the policy before <br>
signing the statement.<br>
Once signed by the signer the signed metadata is sent back to the <br>
requester.<br>
L0Req -- (ms_L0Req + SK[L0Req]) --> FO<br>
<br>
L0Req <-- FO(ms_L0Req + SK[L0Req]) --- FO<br>
<br>
L1Req -- (ms_L1Req + SK[L1Req]) --> L0Req<br>
<br>
L1Req <- L0Req(ms_L1Req + SK[L1Req] + FO(ms_L0Req+SK[L0Req])) - L0Req<br>
<br>
An example of the construction of a compounded metadata statement. The <br>
Level 0 Requester (L0Req) sends a metadata statement request to the <br>
federation operator (FO).<br>
<br>
--------------------------------------------<br>
3. Verifying the Metadata Statement<br>
--------------------------------------------<br>
<br>
Verifying a metadata statement, you first grab the innermost signed <br>
metadata statement. If this is signed by a FO, you have the public part <br>
of the signing keys from then you can verify the signature of the <br>
metadata statement. If the verification concludes that the signature was <br>
correct you can now take the signing keys that were included in the <br>
signed document and use those to verify the second innermost signed <br>
metadata statement. And so on.<br>
<br>
def unpack(jwt, sign_keys):<br>
keys = []<br>
pl = get_payload(jwt)<br>
if 'metadata_statements' in pl:<br>
msl = []<br>
for _iss, statement in pl['metadata_statements'].items():<br>
_ms = unpack(statement, sign_keys)<br>
if _ms:<br>
keys.append(get_keys(_ms))<br>
msl.append(_ms)<br>
pl['metadata_statements'] = msl<br>
elif 'metadata_statement_uris' in pl:<br>
msl = []<br>
for _iss, uri in pl['metadata_statement_uris'].items():<br>
statement = html_get(uri)<br>
_ms = unpack(statement, sign_keys)<br>
if _ms:<br>
keys.append(get_keys(_ms))<br>
msl.append(_ms)<br>
pl['metadata_statements'] = msl<br>
else:<br>
return verify_signature(ms, pl['iss'], sign_keys):<br>
<br>
if verify_signature(ms, pl['iss'], keys):<br>
return pl<br>
<br>
- Mike<br>
<br>
------------------------<br>
Michael Schwartz<br>
Gluu<br>
Founder / CEO<br>
<a href="mailto:mike@gluu.org" target="_blank">mike@gluu.org</a><br>
<a href="https://www.linkedin.com/in/nynymike/" target="_blank">https://www.linkedin.com/in/nynymike/</a><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>