[Openid-specs-ab] Please Either ABSTAIN or OBJECT from the Federation Spec Vote

Mike Jones Michael.Jones at microsoft.com
Wed Jul 18 14:19:01 UTC 2018


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 http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006794.html 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 http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180611/006795.html, and indeed, in the public blog post about the IPR review http://openid.net/2018/06/08/public-review-period-for-openid-connect-federation-specification-started/.



Thank you again for taking the time to review the specification.



                                                       -- Mike



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".

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Jeff LOMBARDO via Openid-specs-ab
Sent: Wednesday, July 18, 2018 9:17 AM
To: mike at gluu.org
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from the Federation Spec Vote

Hi Mike,

From my short interaction with  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).

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.

JF


Le mar. 17 juill. 2018, à 22 h 31, Mike Schwartz via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> a écrit :
OpenID Connect Group,

I got an email notification today that the vote for the Implementer's
Draft of the Connect Federation spec is active now.

There has been no discussion of this spec on the list. We had two
comments--both negative--and neither one really discussed. It reminds of
the FCC vote on Net Neutrality... all comments negative... APPROVE!

I do not want to implement this spec, which is saying a lot because Gluu
is keenly interested to see multi-party federations move forward for
OpenID Connect.

I think we need more discussion, more community involvement, more
outreach to stakeholders, and more consensus before we move to the next
step.

If you have not read and considered this spec, I would ask you to at
*ABSTAIN*.

If you find the following three sections totally incomprehensible, I
would ask you to *OBJECT*. I think this fails the mission of Connect
which is to make guidelines which are developer friendly.

--------------------------
1. BASIC (!) Components:
--------------------------
To describe Compounded Metadata Statements, we need a way of describing
the different components in such a statement. These are the basic
components:

ms_X

Metadata Statement signing request by X without signing keys and signed
metadata statements.
SK[X]

Signing keys that belong to X
X(MS)

Metadata Statement signed by X
A(ms_B + SK[B])
Using these basic components, we can now describe a simple signed
Metadata Statement as:

(ms_C + SK[C])
(ms_C + SK[C] + A(ms_B + SK[B]))
Creating a compounded metadata statements involves adding previously
signed metadata statements to the request before signing it. So, if we
start off with C sending this signing request to B,

B(ms_C + SK[C) + A(ms_B + SK[B]))
This is the resulting compounded metadata statement:

--------------------------------------------
2. Constructing a Signed Metadata Statement
--------------------------------------------

Constructing a Signed Metadata Statement
These are the steps that are performed to construct a signed metadata
statement. A metadata signing request may be about one specific entity
or a group of similar entities.

The requester constructs a signing request by collecting the necessary
relying party or provider metadata as described in Section 3.
If this is about the top most metadata statement (ms_0) then no metadata
statement will be added to the metadata statement. If it is a more
specific metadata statement (ms_1...n) then more general metadata
statement/-s MUST be added. Dependent on setup the metadata statement
can be added by the requester or the signer.
The metadata statement is transported to the signing party. In the case
of ms_0 this MUST be the FO. If it is ms_1 it is the L0Req. If it is
ms_2 it is the L1Req and so on.
The signing party verifies the information in the metadata statement,
modifies and/or adds more information according to the policy before
signing the statement.
Once signed by the signer the signed metadata is sent back to the
requester.
L0Req -- (ms_L0Req + SK[L0Req]) --> FO

L0Req <-- FO(ms_L0Req + SK[L0Req]) --- FO

L1Req -- (ms_L1Req + SK[L1Req]) --> L0Req

L1Req <- L0Req(ms_L1Req + SK[L1Req] + FO(ms_L0Req+SK[L0Req])) - L0Req

An example of the construction of a compounded metadata statement. The
Level 0 Requester (L0Req) sends a metadata statement request to the
federation operator (FO).

--------------------------------------------
3. Verifying the Metadata Statement
--------------------------------------------

Verifying a metadata statement, you first grab the innermost signed
metadata statement. If this is signed by a FO, you have the public part
of the signing keys from then you can verify the signature of the
metadata statement. If the verification concludes that the signature was
correct you can now take the signing keys that were included in the
signed document and use those to verify the second innermost signed
metadata statement. And so on.

def unpack(jwt, sign_keys):
     keys = []
     pl = get_payload(jwt)
     if 'metadata_statements' in pl:
         msl = []
         for _iss, statement in pl['metadata_statements'].items():
             _ms = unpack(statement, sign_keys)
             if _ms:
                 keys.append(get_keys(_ms))
                 msl.append(_ms)
         pl['metadata_statements'] = msl
     elif 'metadata_statement_uris' in pl:
         msl = []
         for _iss, uri in pl['metadata_statement_uris'].items():
             statement = html_get(uri)
             _ms = unpack(statement, sign_keys)
             if _ms:
                 keys.append(get_keys(_ms))
                 msl.append(_ms)
         pl['metadata_statements'] = msl
     else:
         return verify_signature(ms, pl['iss'], sign_keys):

     if verify_signature(ms, pl['iss'], keys):
         return pl

- Mike

------------------------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org<mailto:mike at gluu.org>
https://www.linkedin.com/in/nynymike/
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180718/02424186/attachment-0001.html>


More information about the Openid-specs-ab mailing list