Two names for the same thing: trust_mark_id and id

[Michael Jones]

Some listing and status requests use the "id" request parameter. Some use the "trust_mark_id" parameter to mean the same thing. We should pick one. Given that we're using the "id" claim, I'd suggest changing instances of "trust_mark_id" to "id".

‌

[Vladimir Dzhuvinov]

I’d propose the opposite - to consolidate around trust_mark_id instead of id.

For an endpoint or resource that is only about Trust Marks it is okay to have a query parameter called id . If the endpoint or resource is not purely about Trust Marks, e.g. the listing endpoint, it’s better to have a more specific query parameter, i.g. trust_mark_id. This is convention when designing APIs. When considering the query parameters and how to name them to take into account what the resource is about.

[Giuseppe De Marco]

I agree with Vladimir, I’m in favor of trust_mark_id

‌

[Michael Jones]

Are you also advocating for changing the id claim to trust_mark_id in Trust Marks and Trust Mark delegation JWTs - as in https://openid.bitbucket.io/connect/openid-federation-1_0.html#name-trust-mark-claims and https://openid.bitbucket.io/connect/openid-federation-1_0.html#name-trust-mark-delegation-claim ?

I don’t feel strongly about this, but I think we’re better off registering and using a generic id claim. https://bitbucket.org/openid/connect/pull-requests/654 performs this registration.

[Vladimir Dzhuvinov]

I wasn’t aware of this JWT claim, thanks. Let me read what we have there.

[Vladimir Dzhuvinov]

I would keep the Trust Mark id claim as it is. The JWT is typed and has a single, clearly defined purpose - to represent a Trust Mark, the id that goes into it is its identifier.

Other specs & protocols that need a generic id as a claim (not the jti) will be able to use that - great.

‌

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/661

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/661