Two names for the same thing: trust_mark_id and id
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".
Comments (7)
-
-
I agree with Vladimir, I’m in favor of
trust_mark_id
-
reporter Are you also advocating for changing the
id
claim totrust_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. -
I wasn’t aware of this JWT claim, thanks. Let me read what we have there.
-
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, theid
that goes into it is its identifier.Other specs & protocols that need a generic
id
as a claim (not thejti
) will be able to use that - great.
-
reporter - changed status to open
Will be fixed by https://bitbucket.org/openid/connect/pull-requests/661
-
reporter - changed status to resolved
- Log in to comment
I’d propose the opposite - to consolidate around
trust_mark_id
instead ofid
.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.