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

Chris Phillips Chris.Phillips at canarie.ca
Wed Jul 18 19:50:05 UTC 2018

I also voted "Approve" and align with Nick on his comments below.

As for visibility, this list may seem quiet but OIDC conversations are quite active in the Research and Education (R&E) space, particularly on this Federation Spec. 
The most recent OIDC Federation workshop saw 50 people in attendance at the last European R&E IT conference a few weeks ago in Trondheim:
Pic: https://twitter.com/TNC_GEANT/status/1007201371777617920
Agenda: https://wiki.geant.org/display/gn42jra3/OIDCfed+Workshop+TNC18

For those not familiar with the R&E community, we are interconnected worldwide from the network layer up and often involved in services at many of those layers. At the federation layer, fifty one federations/countries inter-federate globally through a production service called eduGAIN handling over 4,800 SAML entities circulating on a daily basis (https://technical.edugain.org/ ).  As operators we collaborate together and are looking at OIDC as another protocol to add and scale into our existing trust ecosystem. The workshop illustrates that there's a lot of R&E interest of advancing this spec for our needs.

We also value the OIDF process, and as Mike Jones commented on, progressing to the next step of IPR protection on the multi-step journey to a toward a final spec. This vote helps as we work through implementing prototypes and pilots in our respective regions and at scale globally in R&E before reaching something considered as a candidate for final spec.

Hopefully there will be an uptick in more visible dialogue and discussion as the influx of new OIDF members continues from the R&E community. We are encouraging participation and involvement in OIDF to our R&E community as the OIDF governance/voting model is slightly different than what we in R&E are used to.  We hope to see our community as engaged in the OIDF as we are in other standards bodies but it will take some time.

DISCLOSURE: CANARIE is the R&E Federation operator in Canada, an active member in eduGAIN and other R&E activities, and recent member of OIDF
Chris Phillips  
Technical Architect, Canadian Access Federation, CANARIE| chris.phillips at canarie.ca  |GPG: 0x7F6245580380811D  
LinkedIn: http://bit.ly/CPhillipsLinkedIn |  ORCID: http://orcid.org/0000-0001-5567-4916 

On 2018-07-18, 12:54 PM, "Openid-specs-ab on behalf of Nick Roy via Openid-specs-ab" <openid-specs-ab-bounces at lists.openid.net on behalf of openid-specs-ab at lists.openid.net> wrote:

    I voted 'Yes' because I believe this work needs to be allowed to proceed 
    within the OIDF, and I do not share Mike's concerns, after having read 
    the I-D.
    On 7/18/18 8:19 AM, Mike Jones via Openid-specs-ab wrote:
    > 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
    Openid-specs-ab mailing list
    Openid-specs-ab at lists.openid.net

More information about the Openid-specs-ab mailing list