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

[Pawel Kowalik]

> 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.

> 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.

> 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.

Kind Regards,
Pawel


On Wed, 30 Jun 2021 at 10:45, Roland Hedberg <roland at catalogix.se> wrote:

>
>
> On 31 May 2021, at 12:01, Pawel Kowalik via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> Hi,
>
> > For example, the trust chain works differently than what I was used too
> in X.509. In X.509, the intermediary or trust anchor
> > would issue a certificate binding certain attributes of an entity to the
> public key of this entity. In federation, the chain starts
> > with a self-signed statement of the entity about itself. The
> intermediary or trust anchor then seems to vouch for the public key
> > of the entity the respective federation policy is about? That’s not
> fully clear to me, perhaps I’m the only one.  Moreover, I’m not
> > completely sure I understood how entity statements, metadata and
> federation api relate to each other and work together.
> >
> > I think an overview describing and motivating the design concepts and
> principles would be helpful to readers.
>
> We also made a similar observation when trying to employ this
> specification.
> Namely it is not intuitive how an intermediate or trust anchor could
> express metadata information about an entity it vouches for.
>
> As per 2.1 metadata claim is only possible if iss==sub, meaning only for
> the self-statement and forbidden for all other cases.
> The only way an intermediate X may say something about a leaf Y is
> through metadata_policy by enforcing a value,
>
>
> Correct !
>
> like in this example:
>
>  "metadata_policy": {
>     "openid_relying_party": {
> ...
>       "organization_name": {"value": "NTNU"},
> "trust_level": {"value": 2},
> ...
>     },
>   },
>
> This is however semantically not the same as X issuing a statement that Y
> has a name of "NTNU" and trust level 2.
>
>
> No, it’s not,
>
> OK, so the notion was that since a leaf entity not necessarily knows which
> federations it belongs to, it just publishes
> everything it can do and then it’s up to the opponent to figure out using
> policies what actually should be used in a
> federation the entity belongs to.
>
> This means that the intermediate doesn’t vouch for any information the
> leaf entity is publishing (except for the JWKS)
> it just places boundaries on what of it should be used.
>
> It also means that the specification allows the leaf entity to update its
> metadata without asking all its superiors if it can.
> 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.
> 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.
>
> — Roland
> 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...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210630/2ee7a555/attachment.html>