[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review
roland at catalogix.se
Sat Sep 4 06:31:31 UTC 2021
Define extensions points ?!
There is text as to some places where one could add extensions but we are not explicit.
Should we ?
> On 6 Jul 2021, at 12:55, Pawel Kowalik <pawel.kowalik at ionos.com> wrote:
> Hi Roland,
> Would it be a possible approach to define the extension points into the specification, so that the implementations could take them into account?
> I think Trust Marks in the chapter 4.3 may be a good starting point and it could be generalised to express additional trust information in a more generic way, not only limited to trust marks being a specific use case.
> Kind Regards,
> On Thu, 1 Jul 2021 at 19:00, Roland Hedberg <roland at catalogix.se <mailto:roland at catalogix.se>> wrote:
> Oh, I should mentioned that we at one point in time discussed allowing aggregated/distributed claims in
> the metadata. This could be used for vetted claims.
> Eventually we decided that that would not be in the basic document but perhaps in an extension.
>> On 1 Jul 2021, at 08:36, Roland Hedberg via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>> On 30 Jun 2021, at 12:18, Pawel Kowalik <pawel.kowalik at ionos.com <mailto:pawel.kowalik at ionos.com>> wrote:
>>> > It also means that the specification allows the leaf entity to update its metadata without asking all its superiors if it can.
>>> True and this is fine in many respects when it comes to "technical" metadata, like encryption, capabilities etc.
>>> I think it's not fitting well when it comes to trust related information, which can be expected to be vetted by the federation in some way.
>> Trust as defined in the specification on to encompass trust in that the information you receive is what was sent by another entity to you and that the other entity belongs to a specific federation.
>> If the federation has other rules around trust issues like having everyone sign an legal agreement or rules about every
>> intermediate promising to vet their subordinates metadata that has been defined to outside the specification.
>> We where looking at the least common denominator.
>>> > Whether that is how it will work in reality is anyones guess. In some contexts it’s absolutely OK in other maybe not.
>>> > It’s your choice the specification doesn’t force you to do it in one specific way.
>>> The issue I see is that by not allowing metadata object in the case of sub != iss it's difficult to express trusted relations other than binary: is part of federation or not.
>>> It can also be that the trust is not in the scope of Federations spec, or metadata is not the right place to express it.
>>> From my perspective trust is an important part of any Federation and we should think how the specification can support it the best way.
>> For every federation I’ve been involved in trust has been important.
>> And it’s been expressed in signed documents processes for verification of compliance.
>> What’s also true is that everyone does things a bit differently.
>>> > Now if an intermediate feels responsible for it’s subordinates I would expect it to regularly check that the subordinates metadata
>>> > is within the prescribed boundaries.
>>> Yes, this is possible, as well as it's possible to express things via metadata_policy.
>>> None of these approaches is straightforward and IMHO an expression of an intermediate to tell sth about subordinate could be more direct and simple.
>> I don’t think it would be simpler.
>> - Roland
>> Otium cum dignitate - latin proverb
>> 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
> 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)
Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab