Some questions / remarks

[sklemer1]

oidcfederation/draft/oidcfed.hf.xml

Line 421 in 8243bdb

<t hangText="iss">REQUIRED. The entity identifier of the issuer

Why is this REQUIRED without a sensible default? I would say iss should default to the string in front of /.well-know/openid-federation as IMHO this should be the most common use case. The same holds for all API requests.

oidcfederation/draft/oidcfed.hf.xml

Line 463 in 8243bdb

response MUST be a JSON array including signed entity statements.

Why shall this be an array? Are there use cases where the return could be an array with more than one entry? I can't imagine one atm.

oidcfederation/draft/oidcfed.hf.xml

Line 523 in 8243bdb

<preamble>A non-normative example of a response:</preamble>

How does the Request for this Response look like? e.g. what is the type here? The same holds for the other examples.

oidcfederation/draft/oidcfed.hf.xml

Line 575 in 8243bdb

<t hangText="sub_is_leaf">OPTIONAL. If left out, result should

The last sentence in this paragraph is wrong, I think.

oidcfederation/draft/oidcfed.hf.xml

Line 620 in 8243bdb

<section title="Generic Error Response">

In the text you say it should be sth. else than 200 but the ex shows a 200. Below the ex you say (the signed JWT is truntated) which is strange given the plain JSON in the example and no word about anything signed here (which makes sense because you don't want to waste CPU cycles for signing error responses).

oidcfederation/draft/oidcfed.hf.xml

Line 743 in 8243bdb

<t>A leaf node, such as an OpenID Provider will typically have at

What happens if the 2 announced public keys in the self-issued entity-statement and the one issued by the superior do not match?

And I think one could be clearer explaining here that K1 and K2 correspond to the old and new key from the self-issued statement, NOT self-issued and superior-issued. Actually that the whole algorithm is about the self-issued one.

oidcfederation/draft/oidcfed.hf.xml

Line 776 in 8243bdb

<t>Take into considerations that clients have manually configured

This is pretty crucial and we might want to elaborate on this and/or give a best practice?

oidcfederation/draft/oidcfed.hf.xml

Line 792 in 8243bdb

<t>The metadata for a specific entity can be constructed by starting

can, SHOULD or MUST? I find it confusing to give a non-normative example here.

oidcfederation/draft/oidcfed.hf.xml

Line 814 in 8243bdb

<t hangText="Integer/Floats"><vspace/> The number A is a subset of

This is strange when I think e.g. of key-sizes in claims/metadata. The fed-op perhaps has a claim "min_key_size=4096". Does it make sense to define 'subset' for numbers at all?

[sklemer1]

some more:

oidcfederation/draft/oidcfed.hf.xml

Line 938 in 8243bdb

chose one or more that terminates in one and the same trust

I think we need a MUST choose all chains that lead to the same trust anchor here as it might not be clear for the RP on which bases they should trust each other (i.e. the RP might distrust one of the intermediates). But also the question stands: is there a possibility that an OP trusts an anchor higher up in the hierarchy then the RP (or vice versa).

oidcfederation/draft/oidcfed.hf.xml

Line 942 in 8243bdb

registration under the same entity_id then that registration

Perhaps make clearer that you mean the old/existing registration

oidcfederation/draft/oidcfed.hf.xml

Line 945 in 8243bdb

<t>The OP will now construct an entity statement containing a

In this part the important thing is the trust chain so the RP knows on which bases they communicate but what is the benefit of sending the RP a description of himself? This MIGHT lead to an RP behaving in a way that the OP wants (as in choosing a subset of functionality or so) but I find it it kind of strange and complicating the process and it doesn't guarantee at all that the RP "behaves".

oidcfederation/draft/oidcfed.hf.xml

Line 1011 in 8243bdb

above described extensions in the first two steps of the

Which 2 steps? And in the picture below: Why is there a 2-sided arrow showing DISCOVERY from the OP to the RP?

oidcfederation/draft/oidcfed.hf.xml

Line 1060 in 8243bdb

<section title="Authentication Error Response">

I assume we will fixate these in a later draft with some pre-defined defaults or at least examples? Actually a machine readable error_code only makes sense if we have fixed values. Otherwise we could go by only using the error_description.

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Line 421 in 8243bdb

<t hangText="iss">REQUIRED. The entity identifier of the issuer

I see no problem with defining iss as required without providing a default.

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Line 533 in 1ca9cac

<preamble>A non-normative example of a response:</preamble>

Added an example

oidcfederation/draft/oidcfed.hf.xml

Line 533 in b07c45b

GET /.well-known/openid-federation?

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Line 575 in 8243bdb

<t hangText="sub_is_leaf">OPTIONAL. If left out, result should

Fixed the text

oidcfederation/draft/oidcfed.hf.xml

Lines 602 to 607 in 7d96e88

	<t hangText="sub_is_leaf">OPTIONAL. If left out, result should
	include both leaf nodes and intermediate nodes. If set to
	<spanx style="verb">true</spanx> ,
	the response should contain only leaf nodes. If set to
	<spanx style="verb">false</spanx>, the
	response should contain only intermediate nodes.</t>

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Line 620 in 8243bdb

<section title="Generic Error Response">

Fixed by

5c2e498

[rohe]

"What happens if the 2 announced public keys in the self-issued entity-statement and the one issued by the superior do not match?"

The keys in the self-issued entity statement mentioned in the text are the keys in the metadata part.
Like this:

"metadata": {
    "openid_client": {
        "jwks": { "keys": [ ... ] }
    }
}

Those keys have nothing to do with the signing keys that the superior publishes.

[rohe]

A while ago I proposed that we should have different names for the different claims.
The name jwks is defined in the OIDC standard and refers to keys used in the OIDC protocol.
We should use something different for the keys used to signed entity statements. Something like signing_keys .

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Line 776 in 8243bdb

<t>Take into considerations that clients have manually configured

I actually think "Key rollover for trust roots" is outside the scope of this document.

[rohe]

oidcfederation/draft/oidcfed.hf.xml

Lines 814 to 815 in 8243bdb

	<t hangText="Integer/Floats"><vspace/> The number A is a subset of
	the number B if A is less or equal to B.</t>

There are at least 2 types of numbers. One where the number is a tag and should be handled in the same manner as a string. The other type is where it is really a number and therefor can be deemed to lesser, equal or larger then another number. Key size is somewhere in the middle but should probably best be treated in the same way as strings. Looking through the OIDC standard documents there is no metadata claims that takes integers as values.