Closed OIDF-automation closed 2 months ago
I can confirm what Mike said, as stated here
https://openid.net/specs/openid-connect-federation-1_0.html#section-4
Im really not sure what to think ,but the issue needs to be addressed
OIDC Federation:
1. allows new metadata types to be defined to support use cases outside OpenID Connect federations.
2. The metadata type identifier will uniquely identify which metadata specification to utilize.
3. The metadata document MUST be a JSON object. Beyond that, there is no restriction.
said that, I can imagine this in an Entity Configuration:
"metadata" : {
"openid_self_issued_provider": {},
"openid_credential_issuer": {},
}
even if the openid_credential_issuer
may be simply configured as oauth_authorization_server
this should be valid also for OpenID4VP, it could be defined as oauth_authorization_server
so guess the recommendation is to define in the OpenID4VC specs if needed?
PS openid_credential_issuer
should not use oauth_authorization_server
because it is a resource server, and has a separate metadata file from the AS per the VCI spec.
Good, I wrote it then i delete and that was good, as optionally mixed with oauth protected resource if both services are on the same entity. All returns, thank you for the hint
Regarding the OIDC Federation Entity Type oauth_resource
, [here](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.1.2) I read
If the Credential Issuer metadata contains an authorization_server property, it is RECOMMENDED to use a resource parameter [RFC8707]
whose value is the Credential Issuer's identifier value to allow the AS to differentiate credential issuers.
@Kristina what about including an example or a guidance in the Metadata section [here](https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#section-10) to clarify the role of OAuth protected resource according to https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata?
please correct me if something is wrong
It’s absolutely appropriate for specs other than the Federation spec to define any new entity types that they need.
As discussed on the 13-Jan-23 Federation Editors' call, we believe the question asked in the issue has been answered. We plan to close this on that basis in a week unless a reason to keep it open is raised.
A week has passed with no further comments. Closing during the 20-Jan-23 Federation Editors' call, as proposed last week.
I think we were discussing if we need a text in openid4vc specs and I don't have an answer yet. it should not be closed yet.
I’ve learned that Verifiers/RP uses "client_metadata" as defined in OpenID4VP. It's so wide ... considering that it is a just VC verfifier, but that would be another story.
OpenID4VCI defines openid-credential-issuer
and it makes sense.
Then we should have also wallet_provider
?
The new entity types proposed, as a result of the experience of the implementers, are listed below:
while the wallet instance metadata should be carried in the wallet instance attestation.
@peppelinux is there additional implementation experience on this? is this still needed?
From our implementation experiences in openid4vci, we've gained valuable insights and have been able to distinguish between the metadata oauth_authorization_server
and openid_credential_issuer
, underscoring their distinct roles.
The focus of this discussion is on defining metadata types that align with the specific capabilities of each entity within the protocol.
For example, within the wallet ecosystem, we've identified the need for specific metadata claims for the relying party, indicated by the HTTP request parameter client_metadata
. In this process, we're also introducing a new entity, the wallet relying party. This distinction has highlighted the necessity for defining unique metadata types tailored for the wallet ecosystem, such as:
wallet_relying_party
wallet_provider
These distinctions helps us in accurately defining the roles and capabilities of entities within the wallet ecosystem.
Guiseppe's comment seems pertinent to me.
It appears evident that OpenID4VP should remain a protocol-specific application, distinct from trust framework-specific implementations, such as those concerning OpenID Federation metadata types.
Given this perspective, it would be better to define such properties outside of this specification to maintain clarity and focus within the protocol's scope. This approach ensures that OpenID4VP can continue to evolve effectively without the complexities introduced by overlapping with trust framework specifics.
Therefore I'm prone to close this issue.
Is the situation that to use federation with OID4VP & VCI that new entity types like wallet_relying_party
and wallet_provider
do need to be defined? If so we still need to decide where those will be defined?
openid federation already seems to be defining a lot of entity types. to me, it sounds like EUDIW specific entity types should be defined there.
no response. closing for now.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1781
Original Reporter: KristinaYasuda
Brought up during Connect call. I am honestly not sure. MikeJ said it is up to the editors of OID4VP. guidelines how to think about the need would be appreciated.