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

Pawel Kowalik pawel.kowalik at ionos.com
Tue Jul 6 10:55:21 UTC 2021


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,
Pawel


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
> 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
> 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210706/ae9921e0/attachment.html>


More information about the Openid-specs-ab mailing list