1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Should RS have a separate metadata file from the AS?

Issue #1632 resolved
David W Chadwick created an issue

One of our implementors has come accross the following metadata issues which we would appreciate being clarified.

  1. If an implementation has a separate OAuth2 server and Issuing/Resource server, should there be two separate metadata files or can one combined file be used for the VC Issuer?
  2. If the OAuth2 server uses one JWK for signing the access_tokens, and the Issuing server uses another JWK for signing the issued credentials, how can this be indicated in a single metadata file with a jwks_uri parameter. The “use” claim does not differentiate between different signing uses of the two keys. Do we need to register a new “use” with IANA such as vc_sign?

‌

Comments (28)

  1. Torsten Lodderstedt

    Excellent questions ;-)

    re 1: one could use the same metadata file for such a setup. I have seen cases where the AS’s metadata file is used to convey data for a couple of RSs (just because it is convenient).

    re 2: you can use the same metadata and JWKS URL and different keys identified by their key ids (“kid”). You could also use different metadata, which ties back to issue #1607

  2. David W Chadwick reporter

    At the OIDC meeting on 8 Sept the participants decided that having two metadata files was the best option as it provided the greatest flexibility i.e. the same OAuth server could be used by multiple resource servers, or a resource server could be protected by multiple OAuth servers. This also solves the issue of different signing keys, as each type of key will now have its own jwks_uri parameter. The “use” claim was not designed to differentiate between fine grained key usages, but only between encryption and signing.

    However at the following OIDC SIOP meeting on the same day, the participants did not agree with this and thought that one metadata file was the best solution.

  4. David W Chadwick reporter

    The only outstanding issue now is if two metadata files (with correspondingly different DNS names) are used, which name goes in the Issuer field of the Initiate Issuance Request. Perhaps some clarification of this is needed in the spec, as the wallet will need to read in two metadata files.

  5. gffletch

    If only one metadata file is used, doesn’t this limit deployments? To David’s question point above, what if the two services are on different domains? Doesn’t that require two different metadata files?

  6. David W Chadwick reporter

    Talking with my implementors we think that the following is the most flexible solution to this issue

    1. The initiate issuance request contains the URI of the Issuing service
    2. Optionally, the metadata of the issuing service is stored at a new well known end point e.g. vc_issuer_configuration (depending on the resolution of issue #1607)
    3. A new metadata item is added to the issuing service metadata which is the URI of the OAuth server.

    We think this works for both deployment models.

    In a single service deployment with one metadata file and with the OAuth and Issuing services having the same URI, then a wallet will first read in the vc issuer configuration, then see that the name of the OAuth server is the same as the issuing service, and not read in another metadata file.

    In a dual service deployment with two metadata files and different URIs for OAuth and Issuing services, then the wallet will first read in the vc issuer configuration, then see that the name of the OAuth server is different to that of the issuing service, and will read in the metadata file of the OAuth server using its well known endpoint.

    If people agree with this I will write a PR for it

  7. David W Chadwick reporter

    @Torsten you said “you can use the same metadata and JWKS URL and different keys identified by their key ids (“kid”).” Unfortunately this does not work, because a verifier that obtains a VC that is signed by the access token key rather than the Issuer key (say because the OAuth administrator used it to create a fake VC) will not be able to know that this is wrong because both keys are in the Issuer’s metadata. An enhancement of the “use” claim would have solved this, but this has been ruled out. So the only other solutions we can think of to solve this are

    either use two separate metadata files, one for the Issuer and one for the OAuth server, and each points to its own key(s).

    or in the case of one metadata file have two different JWKS URLs, one that points to the issuer’s key(s) and one that points to the access token key(s).

  8. Daniel McGrogan

    +1 to separating the issuer metadata from the AS metadata. I would suggest that the new metadata URI is an RS metadata which contains VC Issuer data.

  9. Torsten Lodderstedt

    Unfortunately this does not work, because a verifier that obtains a VC that is signed by the access token key rather than the Issuer key (say because the OAuth administrator used it to create a fake VC)

    I hope the same administrator won’t fake id tokens since those two use cases are not differentiated by the OAuth/OpenID metadata specs.

    If we introduce dedicated metadata for the issuance endpoint, there needs to be a link to the corresponding authorization server and we need to define whether the issuance issuer needs to be passed in the authorisation data.

    However, authorization and credential issuer are very tightly coupled. For example, the pre authorized code belongs to the domain of the authorization server, not the credential issuance API. My feeling is we will run into several issues by splitting it. I think the current model is simple and works. As David pointed out, added another claim for VC signing keys would server the purpose, in the same way a another metadata file on the same issuer URL.

  10. David W Chadwick reporter

    Here is the algorithm for the wallet to determine whether one or two metadata files are in use by the issuer. First we change the issuer’s metadata file contents to say that one of either token_endpoint or oauth_service properties must be present in the issuer’s metadata, but not both or neither.

    1. Read in the issuer’s metadata from the well.known endpoint
    2. If the token_endpoint property is present then there is just this metadata file.
    3. If the oauth_service property is present, then read in the Oauth2 servers metadata from its well known endpoint.
    4. If both token_endpoint and oauth_service properties are present fail with an error invalid metadata.
    5. If neither are present then fail with an error invalid metadata.

    ‌

  12. David W Chadwick reporter

    There is issue #1607 specifically asking this question. So I suggest we bikeshed the new well known term in that issue and then ask IANA to register it. I suggested /.well-known/vc-issuer-configuration as a strawman for starters.

  13. Torsten Lodderstedt

    The spec designates the issuer as “Credential Issuer”. What about /.well-known/credential-issuer-configuration?

    Beside that I’m not sure whether this configuration is OpenID specific or more general in nature. If it would be OpenID specific, I would lean towards .well-known/openid-credential-issuer.

  14. David W Chadwick reporter

    Honestly I do not mind. I will let those people more expert in OIDC and its culture determine the best string to use and we will use it.

    ‌

  15. Kristina Yasuda

    +1 to separating Resource Server (Credential Issuer) metadata.

    As has been pointed out in the connect call several times there are use-cases where credential issuer cannot host resource server metadata under a .well-known endpoint under the credential issuer’s domain. suggest we add additional parameter in the initiate issuance request where the issuer can pass an entire URI where the RS metadata is hosted (metadata is very likely needs to be signed by the issuer’s key since it is hosted in under domain controlled by another entity.)

  17. David W Chadwick reporter

    What about /.well-known/credential-issuer on its own, without appending either “-metadata” or “-configuration” to the string. This would follow OAuth2 which uses "/.well-known/oauth-authorization-server".

  19. Kristina Yasuda

    since we do not expect credential issuer to have oauth/oidc functionality, it makes sense for it to have a separate .well-known/file hosted.

    the way issuer server metadata is defined right now is with assumption that it is one file - needs to be revisited to make clear how credential issuer metadata parameters are used.

    ‌

  22. Torsten Lodderstedt

    since we do not expect credential issuer to have oauth/oidc functionality, it makes sense for it to have a separate .well-known/file hosted.

    Could you please define “credential issuer”? For me the credential issuer is the set of all endpoints relevant for the issuance, which includes OAuth AS functionality.

    ‌

  23. Torsten Lodderstedt

    As has been pointed out in the connect call several times there are use-cases where credential issuer cannot host resource server metadata under a .well-known endpoint under the credential issuer’s domain.

    I would like to understand this limitation. Could you please explain? It seems you are assuming existing ASs could support a new credential issuance API without any changes?

    suggest we add additional parameter in the initiate issuance request where the issuer can pass an entire URI where the RS metadata is hosted (metadata is very likely needs to be signed by the issuer’s key since it is hosted in under domain controlled by another entity.)

    How would you cope with other scenarios, like a wallet requesting credential issuance during credential presentation request? What data would such a wallet need and how would it be provisioned?

    ‌

  26. Kristina Yasuda

    Could you please define “credential issuer”? For me the credential issuer is the set of all endpoints relevant for the issuance, which includes OAuth AS functionality.

    Credential Endpoint, rather.

    Could you please explain? It seems you are assuming existing ASs could support a new credential issuance API without any changes?

    yes, existing ASs can reuse existing metadata, but that does not mean no changes to the code at all - supporting new scopes/authorization details, etc.

    How would you cope with other scenarios, like a wallet requesting credential issuance during credential presentation request? What data would such a wallet need and how would it be provisioned?

    honestly, not sure right now. how would a wallet know issuer URL in issuance during presentation (to be able to append .well-known to it)?

  29. Log in to comment
Assignee
–
Type
proposal
Priority
minor
Status
resolved
Component
Credential Issuance
Milestone
–
Version
–
Votes
0
Watchers
7
Jira: the preferred issue tracker for Bitbucket. Join the team!