[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review

Sat Sep 4 06:29:28 UTC 2021

Hi

To add to this:

(1) Having an entity being both an intermediate and a leaf would indeed be best handled by having
2 entity IDs, one for the intermediate and one for the leaf.

(2) This is a breaking change that we would not like to adopt.

(3)-(4) Not sure I get what he’s asking for. Please elaborate

(5) Would not scale. Even the Federation API ”Entity Listings” is problematic.

(6) If there is an agreed on list of operationally impacting policy fields, sure !

(7)(8) Prioritizing authority_hints doesn’t work since priorities are in the eye of the beholder.

(9) Would like to know more about how this would work.

(10) Can make it OK to use JWKS or JWK. 

> On 30 Jun 2021, at 09:57, Roland Hedberg via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi David,
> 
>> On 28 Jun 2021, at 23:00, David Waite via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>> 
>> I have other feedback items but would like to focus on a particularly thorny one; entity statements are perhaps broad and dynamic enough that they are both challenging to understand as a concept and have business logic involved in evaluation. Some of the flexibility around them I believe could also result in interoperability issues.
>> 
>> To summarize my understanding, an entity statement JWT defines multiple new concepts:
>> 
>>  1. Self-issued statements which provide a metadata structure superset of OpenID Connect Discovery, supporting multiple protocols/roles as well as defining them as a signed document format.
>> 
>>  2. Specific federation metadata representing information about the entity's role within the federation
>> 
>>  3. One or more authority hints, pointers to parent intermediate entities which are expected to offer trust this entity, hopefully chaining up to an authority that a party processing entity statement has a trusted relationship with.
>> 
>>  4. Trust statements in the form of an ’sub’ which is a separate child entity, creating a trust chain
>> 
>>  5. Constraints on the ability for a child entity to make trust statements about other descendant entities
>> 
>>  6. JWT and metadata mustUnderstand-style critical sections.
>> 
>>  7. Trust marks, which are basically external statements but are outside the scope of the defined trust hierarchy.
>> 
>> Which claims can be within an entity statement depends on whether you are a leaf node or intermediate node.
> 
> Correct
> 
>> Which claims can be used _also_ depend somewhat on context, as you can fetch iss=sub statements about an entity, and iss != sub statements about the trust of another entity. 
> 
> True
> 
>> Finally, I can share return different entity statements per-entity - leveraging the ‘aud’ claim on the federation endpoint and by submitting different RP entity statements to OPs on explicit federated registration. This includes an intermediary dynamically changing metadata policy for a particular audience.
> 
> True
> 
>> That the intermediate can offer metadata as well as policy creates issues, including one of what metadata policy is applied to the intermediary or not.
> 
> Not completely sure I understand what you’re saying here.
> 
>> Finally, note that since you can provide both authority hints and trust statements, you effectively form a directed cyclic graph.Assuming no cycles, you could still wind up resolving metadata differently for two different paths from an entity to a single trust root - one through a intermediate node that performs a metadata policy ‘add’ or ‘default’ and one which doesn’t.
> 
> True, intermediates are allowed to define their policy for their descendants as long as it is not in conflict with the federations policy.
> 
>> I would propose:
>> 
>> 1. Consider the impact of intermediates being able to issue to both provide services themselves and offer services to other child entities. Clear rules need to be defined here about impact and interoperability, e.g if metadata policy applies to oneself or only to children. I lean towards an intermediary who wants to offer direct services must create their own leaf (since URL are cheap), but realize there may be services that make sense to provide at the root authorities, e.g. federation-wide trusted services.
> 
> I too would prefer intermediates to separate their role as intermediate from possible roles as service providers.
> As it is possible to connect service providers directly to the trust anchor without any intermediates in-between there is as I see it no conflict here.
> 
>> 2. Consider defining three different kinds of statements - an entity metadata statement describing metadata, a ‘policy’ statement describing authority and dictating policy of child entities as a group, and a ’trust’ statement which declares trust of a particular child entity (along with additional trust chain restrictions). 
> 
> OK, could possibly work.
> So would the chain of events for an RP to find out about an OP then be:
> 
> 1) request the OPs metadata
> 2) for each authority hint request the intermediates ‘metadata’ statement and then the intermediates ‘policy’ and ‘trust' statements for the OP ?
> and so on...
> 
> So the intermediates gets 3 requests instead of one or am I missing something ?
> 
>> If metadata statements can’t be issued by intermediaries and root authorities, these actually would become three separate kinds of JWTs, possibly distinguished by `typ`. If an intermediary can offer metadata/services, this becomes a conceptual differentiation - we define these statements first as interrelated concepts, then define how we put them into JWTs.
>> 
>> 3. Provide a statically resolvable form for all JWT-protected statements - e.g. a URL resolution process like a no-parameter GET from a `well-known` location. Trust statements are the only piece which would need a dynamic resolution process due to number of child entities, and this could be declared as part of the policy statement.
> 
> 
>> 4. Eliminate via a combination of technical and conformance measures the ability to provide custom policy statements and custom metadata statements. A technical measure would be making the well-known resolution authoritative, with a requirement that the statement not be distinguished by the requesting audience or authentication. Other systems (such as a trusted metadata resolution endpoint) would build on top of the authoritative information.
> 
> 
>> 5. Define an alternative method over a trust statement resolution endpoint to statically provide an authoritative list of trust statements - such as embedding the trust statements as a JSON array within a policy statement. This should allow for all federation metadata to be served statically.
> 
> This would only work for small federations. The response would be prohibitory large as the federation grows.
> And this is why we only return entity IDs from ‘entity listing’ at the Federation API.
> 
>> 6. Forbid the use of `default` or `add` metadata operations on any operationally impacting policy field - An intermediary can set a default tos_url, but I can’t add a registration_endpoint or a id_token_signing_alg.
> 
> OK, can see the benefits of this but who are the operationally impacting policy fields ?
> 
>> 7. Define a default behavior for authority_hints where it is a priority list, with the ability to specify other behaviors via future critical claims in the statement.
> 
> Right, this has been on the discussion list time and time again. 
> What we almost always end up with is that the usefulness of a priority list is pretty limited because the entity publishing the list may not know who the requestor is and even so may not know itself which federations it belongs to. So what should it base the sorting of the list on ?
> 
>> 8. Using this default behavior of authority_hints, define a specific resolution steps such that there is a deterministic resolved form of metadata based on a given set of statements. Note now that these inputs and thus this output is invariant to the audience who is doing this evaluation.
>> 
>> 9. Do not define a broad federation_api_endpoint - define purpose-specific endpoints (since URLs are cheap), The only endpoint needed is to retrieve trust statements from an intermediary. The current form prevents discovery of operational features on the federation api. Note that I already did this above with a trust statement resolution endpoint in policy statements, leaving the federation api endpoint as defined entirely for optional behavior (resolution of statements, evaluation of statements, etc)
> 
> See my answer to (2)
> 
>> 10. Evaluate whether a trust statement and the entity metadata statement both need to support JWKS e.g. multiple keys. I would expect a trust statement to only use a single JWK.
> 
> It would.
> 
> Thanks,
> 
> — Roland
> 
> Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826) 
> 
> _______________________________________________
> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
— Roland

There is nothing you cannot prove if your outlook is only sufficiently limited. (Dorothy L. Sayers, ”Whose body?”)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210904/f3f7169c/attachment.html>