breaking change: .well-known/jwt-issuer renamed to .well-known/jwt-vc-issuer #118
Conversation
|
might be a stupid question: but given the latest change from VC-SD-JWT to SD-JWT VC, shouldn’t the metadata location name be |
peppelinux
changed the title
|
Potentially fixes #101 |
|
I propose that we wait to resolve the discussion in #101 before merging this. |
|
Marked as DO NOT MERGE since we have to wait for the discussion in #101 to resolve first. |
| configuration available at the path formed by concatenating the string | ||
| `/.well-known/jwt-issuer` to the `iss` claim value in the JWT. The `iss` MUST | ||
| `/.well-known/jwt-vc-issuer` to the `iss` claim value in the JWT. The `iss` MUST |
There was a problem hiding this comment.
why are we intentionally breaking compatibility with oidc?
There was a problem hiding this comment.
OIDC uses a different path, so I don't think it breaks compatibility with it. (this path is being defined in this spec, because we were surprised to find that a generic jwt-issuer .well-known path has not been defined, but at the same time maybe it was not defined because it is too generic and this path needs to be scoped to jwt-vcs, not sure yet)
There was a problem hiding this comment.
@OR13 A SD-JWT VC is not an ID Token and a verifier does not know how a SD-JWT VC was issued. So I don't see the relationship to OIDC: Could you please explain what "breaking compatibility with OIDC" means?
| configuration including `jwks_uri`: | ||
|
|
||
| ``` | ||
| { | ||
| "issuer":"https://example.com", | ||
| "jwks_uri":"https://jwt-issuer.example.org/my_public_keys.jwks" | ||
| "jwks_uri":"https://jwt-vc-issuer.example.org/my_public_keys.jwks" |
There was a problem hiding this comment.
provide a full example of the dereferenced resource.... something like:
{
"keys": [
{
"kid": "..."
}
]
}
|
I added a related PR here: w3c/vc-jose-cose#111 |
There was a problem hiding this comment.
i do not think we have enough data points to make this decision, yet. this mechanism /.well-known/jwt-issuer/ is meant to be a generic mechanism, applicable beyond only VCs and I don't think it conflicts with other .well-known paths like in federation (partially because we do not have clarity around what other metadata to put under that path other thank JWK...)
There was a problem hiding this comment.
I would leave the name .well-known/jwt-issuer. This is a general-purpose capability usable by other kinds of JWTs. It just happens to being defined in this spec.
There's nothing wrong with that. In fact, specs often do that, to the benefit of others wanting to use these more-general-purpose facilities. They get put in IANA registries, from which their definitions are discoverable.
|
@selfissued what about having jwt_issuer as a oidc federation metadata type? If this well known resource Is a generic purpose metadata that every kind of entity can expose, how to check the protocol metadata It carries? It might be and OpenID provider and a relying party and an RS or whatever, without a unique identifier It wouldnt be good for metadata but Just for Key attestation So the difference between this and x509 would be just the data format. Or, differently, in jwt-issuer there would space for multiple metadata with unique type identifiers like the federation EC? |
|
Why not define, |
That's the same though I had, if It Is Just for Key attestation let's give to it the semantic It should |
|
Ok dears, may I change the endpoint name to |
|
The existing name is good. |
|
names are very often semantical or cosmetic and driven by personal tastes or objective meanings, that's just a name. I would like to ask which are the scopes of this endpoint, if it is just for key attestation or also for metadata. my answer is, by defining several metadata types, as already done in federation entity configuration but this seems not clear, or out of scope for now, or let them think about this later on. |
I like this more, having a well known location to associate a set of JWKs to seems generally useful, if you have additional metadata to communicate to parties that should be served from higher level well-known endpoints that are defined for that protocol / application. |
|
if the purpose of this endpoint is only for serving jwks, I think |
|
Any path name would be fine (e.g., Defining such a well-known path will not prevent the definition of |
|
You could remove the content type from the resource identifier, and use the accept header. GET --accept application/jwk-set+json |
I love this, however I'd prefer two separate endpoints for two different format, since without the definition of any content-type in the request would return a default value, then: Jose or cose Key set? |
|
Server reserves the right to set the content type header or throw a content type unsupported error, but you can also probably say jwk-set+json is the default when requesting the endpoint be reserved.... openid-configuration is known to be application/json, and didn't reserve
|
|
overseeded by #189 |
this PR resolves#101more discussion is needed