jwt-issuer renamed to vc-jwt-issuer

[peppelinux]

Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading.

Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to

.well-known/vc-jwt-issuer

[awoie]

The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.

[awoie]

@tlodderstedt what do you think?

[awoie]

@peppelinux is there a reason the JWT Issuer should not be used with something else than VCs?

[peppelinux]

There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks

Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem

SD-JWT-VC should define only the resources needed for the solution It defines

[tlodderstedt]

I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).

[peppelinux]

I agree @tlodderstedt,

Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata

Also the verifiable attestations related to the entity may be available in it

[awoie]

To me this sounds reasonable. I will update the spec accordingly.

[TakahikoKawasaki]

(As a record, I repeat my question I made elsewhere in the past.)

Why is it necessary to introduce a new /.well-known path, especially if the expected content is just like below (excerpt from "5.2. JWT Issuer Metadata Response")?

{
   "issuer":"https://example.com/",
   "jwks_uri":"https://jwt-issuer.example.org/my_public_keys.jwks"
}

Isn't the jku JWS header parameter (RFC 7515 Section 4.1.2) like below sufficient?

{
  "alg": "ES256",
  "typ": "vc+sd-jwt",
  "jku": "https://jwt-issuer.example.org/my_public_keys.jwks"
}

[tlodderstedt]

(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier. And not to forget, this well-known location also could work well with openid-federation. Moreover, any additional VC issuer metadata we will come across can be added to this endpoint. BTW: I think a dedicated issue would be the better place for this discussion.

[Sakurann]

I am actually in favor of jwt-issuer. This mechanism is meant to be general enough to be used with not just a 'verifiable credential'. and I don't think anyone would think to use .well-known/jwt-issuer with ID Tokens and Access Tokens, UserInfo responses , etc. that are JWTs.

[peppelinux]

I understand your point @Sakurann, below my thoughts

1. Why defining jwt-issuer for general purpose in a spec that's specialized for VC? Requirement: definition of a specs in IETF for general purpose JWT Issuer metadata (enabling client metadata, that today is only available in openid-federation...)

2. I agree that jwt-vc-issuer semantically collides with credential-issuer, and we should not do collisions

3. why we can't use .well-known/openid-federation? Federation entity discovery is required for the entities that builds trust chain according to the federation specs, nothing prevent to publish all the metadata of all thw "JWT-role" in a single metadata, that should not be signed if request (content-type) asks it in plain text

I suggest to use .well-known/openid-federation to consolidate a unique way to publish all the metadata types and roles of an entity.

coming back to the name change proposal. Why we use the term issuer since the metadata contains also general capabilities not related to the issuance?

in a more general purpose way, wouldn't it be a .well-known/oauth-entity?
then the question: if that entity has more functionalities and roles, being at the same time a RP and a AS, how the metadata should be organized?

We've resolved this issue in openid-federation, with the below schema, where a RP can be also a OP, AS, Client, credential-issuer and so on:
https://github.com/italia/spid-cie-oidc-docs/blob/versione-corrente/docs/common/common_examples.rst#en-11-entity-configuration-response-relying-party

[TakahikoKawasaki]

I'm a little embarrassed, but to be honest, I still don't understand the reasoning. "A stable issuer identifier" is represented by the iss claim, not by the URL of the well-known endpoint, isn't it?

A possible reason for necessity of a well-known path I guess is "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path under the domain."

An example with concrete values would be "to make sure that the host example.com identified by the issuer identifier https://example.com actually exists and is accessible, by forcing JWT verifiers to access a path (/.well-known/{whatever}) under the domain (example.com)."

It might be beneficial to define /.well-known/jwt-issuer as the ultimate fallback general-purpose option for locating the public key required to verify the JWT's signature (not as the sole rule for every VC to follow), especially when it is challenging to reach a consensus on a single method within a limited timeframe among the following.

1. jwk
2. x5c
3. kid starting with did:
4. jku
5. trust_chain
6. /.well-known/openid-configuration
7. /.well-known/openid-federation
8. /.well-known/vc-jwt-issuer
9. ./well-known/openid-credential-issuer
10. /.well-known/jwt-issuer
11. Others

However, maybe I'm still missing something, sorry.

[tlodderstedt]

The well-known endpoint is indeed also a stable identifier. But it depends on a certain well-known location, i.e. different well-known locations are different identifiers.

I'm looking for a stable identifier for the issuer that works across .well-known locations and is not bound to a certain key. That's pretty simple with well-known locations as the iss value can be extended by several different .well-known locations, but the identifier is still the same, right?

So for example, the issuer could use the jwt-issuer mechanism share keys and (at the same time) be part of an OpenID Federation as shown in the following:

/.well-known/jwt-issuer
/.well-known/openid-federation

The same issuer's URL could also at the same time used in an external data structure at the verifier or at a trusted 3rd party.

Effect: I can establish trust in a certain issuer/entity/server that works across different roles/perspectives.

I hope that explains better.