[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review
pawel.kowalik at ionos.com
Fri Jul 9 10:58:07 UTC 2021
Sure, I will draft a proposal and post a PR. Thanks!
On Fri, 9 Jul 2021 at 08:49, Roland Hedberg <roland at catalogix.se> wrote:
> Hi Pawel,
> absolutely ! Could I ask for a text proposal :-)
> 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> 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> wrote:
>> On 30 Jun 2021, at 12:18, Pawel Kowalik <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
>> 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
>> 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
>> — 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)
> — Roland
> Can anything be sadder than work left unfinished? Yes, work never begun.
> -Christina Rossetti, poet (5 Dec 1830-1894)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab