Obtaining metadata just-in-time of the Request is not `registration`?

[Kristina Yasuda]

Calling Mechanisms to Obtain Metadata Just-in-time of the Request defined on Self-Issued OpenID Provider v2 registration might be misleading since RP/OP are not necessarily registering the obtained metadata and treating it as ephemeral?

[Kristina Yasuda]

PR #210

[Tobias Looker]

I agree if the expectation is that the party receiving the metadata (usually the provider) isn’t going to persist this information and return an identifier to the client to use to identify it self in future, then it's not registration its just negotiation.

[Giuseppe De Marco]

I completely agree.

If the content of the registration parameter is actually a metadata, well it would be semantically correct to rename this paramenter as“metadata”. It’s simpler and clearer, and it would be used for any kind of authz negoziations .

We may also adopt a trust mark in the metadata to enable a more interesting trust negotiation … :-)

[Kristina Yasuda]

can do a PR to rename registration to something like negotiation so that we can have a concrete discussion.

[Giuseppe De Marco]

In “9.2.3. Relying Party Registration Metadata Values“ we read Registration Metadata.

Metadata is a well known term in the AAIs from decades.
What do you think to rename registration to metadata?
The content of the paramenter registration is actually a metadata.

Moreover, the registration traditionally happens during the first time the RP gets in touch with a Holder, we know that a RP may change its metadata frequently.
So, I’m wondering, if is it a registration or a simple way to let the Holder know the metadata of the RP?

Additional proposal for a trust negotiation mechanism
The metadata of a RP could be a JWT and not only a JSON and this JWT may be signed by a trusted party (Federation authority or its intermediary).
Differently the metadata can be a JSON and in it could be present a signed artifact (let’s call it trust mark) signed by a trusted party.

I’d prefer the second option (trust mark) because like a badge the RP may expose more than a single trust mark in a single time. For the definition fo trust mark and an overview on it, see OIDC Federation.

The signed payload of a Trust Mark can proofs the aderence of a RP to a trust framework, a regulatory protocol, a specific profile and so on.
In the following example a trust mark assigns to a RP the profile of a public provider of services:

{
  "iss": "https://federation.authority.eidas.eu",
  "sub": "https://trusted-rp.org",
  "iat": 1579621160,
  "exp": 1579621260,
  "id": "https://eidas/certification/relying_party/public",
  "logo_uri": "http://eidas/certification/static/public-service-150dpi-90mm.svg"
}

The Holder, without having ever seen a RP, will look for a specific trust mark, contained in the metadata of the RP submitted during the request.
It validates the signature of this Trust Mark using the public key of the well known authority, and then establishes the trust with the RP, accepting the authz request.

This implementation work even in an offline use case, where the Holder only needs the public key of the trusted authorities (trust mark issuers).
Mind that the expiration value of a trust mark, contained in the exp claim, can be very low. This forces the RP to update their trust mark very frequently, downloading automatically these from the trust mark issuers web services (in OIDC Federation we may have these in the entity statement issued or in the resolve endpoint response).

This proposal could resolve the following issue:
- https://bitbucket.org/openid/connect/issues/1482/static-trust-negotiation-in-a-scenario

[Nat Sakimura]

Some information like policy_url will be and should be persisted at the Wallet as AS, so there indeed is registration happening.

Perhaps it would be a good idea to create a table that compares what is happening during “Just-in-time registration” and “(normal) registration” and finds out if they are similar enough. When we were creating OpenID Connect, the WG agreed that they are both registration so I am against changing it without a very good reason.

[Kristina Yasuda]

PR #227

[Kristina Yasuda]

in “just-in-time registration“, AS does not assign client_id to the Client and does not store any of the metadata received in the request. Hence

When `client_metadata` or `client_metadata_uri` parameters are present, but Self-Issued OP recognizes `client_id` and knows metadata associated with it, Self-Issued OP MUST return an error.

Self-Issued OPs compliant to this specification MUST NOT proceed with the transaction when pre-registered client metadata has been found based on the `client_id`, but `client_metadata` parameter has also been present.

Usage of `client_metadata` or `client_metadata_uri` parameters with `client_id` that Self-Issued OP might be seeing for the first time is mutualy exclusive with the registration mechanism where Self-Issued OP assigns `client_id` to the RP after receiving RP's metadata.

‌