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

Nick Roy nroy at internet2.edu
Wed Jul 18 14:20:42 UTC 2018


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.

Nick

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
> 


More information about the Openid-specs-ab mailing list