Clearer description of metadata construction using explicit client registration.

[Roland Hedberg]

There need to be a clearer description on how metadata is created using explicit client registration.

[Vladimir Dzhuvinov]

With the ability to push / reference the trust chain (unverified) in requests to OPs the no-extra-endpoints argument for choosing explicit client registration over the automatic no longer seems to apply. So I was wondering what arguments remain for an RP (or a federation in general) to choose explicit client registration? Explicit has the significant issue of how an RP can find out whether its registration expired / became invalidated that cannot be solved unless RPs use PAR (referenced below). If there are no strong reasons to use explicit, I wonder whether it could be made obsolete as a registration mode, keeping only automatic and simplifying the entire spec. What are your thoughts on this?

https://bitbucket.org/openid/connect/issues/1594/federation-trust-chain-in-authz-request

[Roland Hedberg]

Well, one big difference between explicit and automatic registration is that if explicit is used then an OP can influence what the RP’s metadata will look like. It can for instance set client_id and client_secret. So from an OP’s point of view I might prefer explicit over automatic. An RP on the other hand might even see it as a feature that the OP can not influence the RP’s metadata.

Anyway, I think it’s a bit premature to mark explicit as obsolete, we have too little experience for that.

[Vladimir Dzhuvinov]

Automatic naturally precludes any sort of OP issued credentials (client_secret), so that’s a valid point for having explicit in a federation that allows secret based client authentication.

About the issue at hand, do you think the metadata construction in explicit can be specified in a clear sequence of steps?

I.e. 1) steps the OP must take; 2) steps the RP must take?

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/283