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

[Roland Hedberg]

> 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/1d76a8a8/attachment.html>