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

Davide Vaghetti davide.vaghetti at garr.it
Wed Jul 18 12:37:26 UTC 2018


Hi Mike,

DISCLOSURE: I'm a federation operator of a SAML2.0-based R&E identity
federation (IDEM), and I can tell that in the R&E Trust&Identity
community there is a lot of interest about the OIDC Federation Spec.

I'm not in both case 1, not-read-the-spec, nor in case 2,
not-understood-a-thing, and I'm willing to APPROVE it.

That said, probably it would help if you could signal what is "totally
incomprehensible" and why in the thee sections below. I searched
backward in the ml to find out if you already signaled some specific
issues, but I found only two messages from you on 2018/06/09.

In one the above messagges you were signaling that in the current
version of the spec it is not clear which OP claims will be part of the
signed metadata_statements and which ones the OP will publish itself. I
agree with that, I even think that this is also true for the RP part.
But, how is this a problem? What will be signed by a superior entity and
MUST be part of the metadata_statements is up to the policy of a
specific federation. The very same can be said for SAML metadata
(saml-metadata-2.0-os), what has to be signed is up to the policy, or
better to a federation profile. And we have a number of organizations
and places where we're taking care of it (the R&E Identity federations
themselves, REFEDS, Kantara, etc.). IMO, it is for the good that is true
also for the OIDC Federation spec.

For this specific issue, how hard will be for a developer to add a
configurable list of claims that MUST be checked in a metadata_statements?

Cheers,
Davide

On 18/07/2018 04:31, Mike Schwartz via Openid-specs-ab wrote:
> 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

-- 
Davide Vaghetti
Consortium GARR
Tel: +390502213158
Mobile: +393357779542
Skype: daserzw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180718/7dae08be/attachment.p7s>


More information about the Openid-specs-ab mailing list