<div dir="ltr">
<span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hi Mike,</span><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">From my short interaction with <span> </span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">JF</span></div>
<br></div><br><div class="gmail_quote"><div dir="ltr">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 :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>