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

Jeff LOMBARDO jeff.lombardo at gmail.com
Wed Jul 18 13:16:39 UTC 2018


 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> 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
> https://www.linkedin.com/in/nynymike/
> _______________________________________________
> Openid-specs-ab mailing list
> 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/933c0c3e/attachment-0001.html>


More information about the Openid-specs-ab mailing list